From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-05-14 05:43:57
Guillaume Melquiond wrote:
> On Tue, 13 May 2003, John Maddock wrote:
>>> One of the first things the configuration header does is:
>>> #if !(defined(_GLOBAL_USING) && (_GLOBAL_USING+0 > 0)) &&
>>> !defined(_STD) # define BOOST_NO_STDC_NAMESPACE
>>> 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>."
>> Getting things correct for the dinkumware lib, is nothing short of
>> Voodoo, they tend not to expose macros that we can use consistently
>> - whatever patches applied.
> Your patch does not fix the problem at all. In my opinion, it can even
> break some working configurations. I would rather use this
> conditional expression:
> # if !(defined(_GLOBAL_USING) && (_GLOBAL_USING+0 > 0 || _CPPLIB_VER
> == 310)) && !defined(_STD)
> since the test _GLOBAL_USING+0 > 0 is false although we want it true
> with Dinkumware 3.10 (_CPPLIB_VER == 310 and maybe other versions but
> I don't know them).
Testing _CPPLIB_VER is incorrect. AFAICS _GLOBAL_USING means "import
identifiers from the global namespace into std:: via using declarations."
_GLOBAL_USING can be 0 when the C library headers put identifiers in std::
and ::, as is probably the case for Intel/Linux; no further "postprocessing"
Under Windows, the C library headers do not put identifiers in std::, and
_GLOBAL_USING=1 can be used as a test whether the identifiers have been
imported into std:: by the <c*> headers. Note that this does not depend on
I think that the right thing to do here is to specifically test for the
problematic configuration (i.e. __ICC && __linux) to avoid breaking
Dinkumware 3.10 on other platforms.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk