Boost logo

Boost :

From: Guillaume Melquiond (gmelquio_at_[hidden])
Date: 2003-05-11 15:01:54

On Sun, 11 May 2003, Guillaume Melquiond wrote:

> The default configuration defines BOOST_NO_STDC_NAMESPACE for this
> compiler. So the library expects to find standard C math functions (the
> ones in <cmath>) in the global namespace. Unfortunately, they are where
> they are supposed to be: in the std namespace. So here is my question: is
> this macro really necessary for this compiler?

Thanks to a suggestion from Gennaro Prota, I did take a look to the
library part of the configuration. The Linux version of the Intel compiler
is shipped with the Dinkumware library (_CPPLIB_VER=310).

One of the first things the configuration header does is:

  #if !(defined(_GLOBAL_USING) && (_GLOBAL_USING+0 > 0)) && !defined(_STD)

However, during compilation, _GLOBAL_USING is defined but without value
and _STD is not defined, so BOOST_NO_STDC_NAMESPACE is set.

I tried to uncover the meaning of these macros, but the only explanation I
found was this sentence of Peter Dimov in another mail: "Dinkumware puts
the names in std:: when _GLOBAL_USING is #defined to 1 in <yvals.h>."

But it doesn't seem to be true anymore since no value is given to
_GLOBAL_USING. And the comment for _GLOBAL_USING in yvals.h says: "*.h in
global namespace, c* imports to std". So it is enough for _GLOBAL_USING to
be defined for the standard C functions to be imported in namespace std.

Consequently I added a test for _CPPLIB_VER==310 (I don't know the
situation for the other versions of the library) in the previous
conditional expression. But it was not enough, BOOST_NO_STDC_NAMESPACE was
still defined. This time, it's in config/platform/linux.hpp:

  // Intel on linux doesn't have swprintf in std::
  #ifdef __ICC

Since there already exists a macro BOOST_NO_SWPRINTF (which is correctly
set), this portion of code is not needed, is it?

In conclusion, stdlib/dinkumware.hpp should take into account the new
versions (which versions of the library other than 3.10 are affected?).
And the lack of swprintf in std:: is not enough of a reason to define
BOOST_NO_STDC_NAMESPACE in platform/linux.hpp since swprintf is already
known to be non-conforming thanks to BOOST_NO_SWPRINTF. Comments?



Boost list run by bdawes at, gregod at, cpdaniel at, john at