Farid Zaripov wrote:
-----Original Message-----
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Friday, June 13, 2008 11:04 AM
To: [email protected]
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: http://svn.boost.org/trac/boost/ticket/2004.
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>.
Martin
