stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: remove_reference
Date Fri, 13 Jun 2008 09:49:37 GMT
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [] On Behalf Of Martin Sebor
>> Sent: Friday, June 13, 2008 11:04 AM
>> To:
>> Subject: Re: remove_reference
>> Namespace pollution causes portability problems because of 
>> the underspecified contents of standard library headers.
>> stdcxx goes to great lengths to avoid introducing symbols 
>> into the std namespace unless required by the standard. For 
>> example, while most other implementations expose the contents 
>> of <cstdio> via <iostream>, stdcxx does not. Similarly, while 
>> a number of other implementations expose the contents of (at
>> least) <ios> when <complex> or <string> are #included, stdcxx 
>> goes to a lot of trouble to avoid it.
>   This things are good in most cases, except one: the most
> implementations
> expose the contents of <ios> via <iomanip>, but stdcxx doesn't. So the
> users
> have to #include <ios> manually along with <iomanip. But many
> programmers
> assumes, that #include <iomanip> should be enough. In the result there
> are
> number or errors like "hex is not a member of std", for example when
> testing
> boost with stdcxx. Most of this errors are fixed in boost after I
> creating the issue
> ticket, but they are appearing in new code! The last one in file, added
> to the svn
> by 4 march 2008:

Yes, this has been a common source of errors despite the standard
being quite clear on which header these manipulators are declared
in. There are also users who expect them to be declared in
<istream> and/or <ostream>. I am sympathetic to the first use
case but less so to the second. IMO, the right way to solve the
problem is to open an issue against the standard to require that
the manipulators be declared also in <iomanip>.


View raw message