Boost logo

Boost :

From: Dave Abrahams (abrahams_at_[hidden])
Date: 2000-06-01 15:41:22


--- In boost_at_[hidden], "Ed Brey" <brey_at_a...> wrote:
> IMHO, we already achieve this balance with BOOST_NO_STDC_NAMESPACE,
> which causes ptrdiff_t to be pulled into namespace std.

Eek! We're doing this already? Well then, far be it from me to
interfere with precedent.

> Less lawyerly, I see the primary advantage of
BOOST_NO_STDC_NAMESPACE
> as maintaining the goal of writing libraries assuming a standard
> conforming compiler, and bending as unintrusively as possible to
work
> around problems. The idea is that eventually, the compilers get
> cleaned up, and then config.hpp becomes an empty file, but none of
the
> other code changes. Obviously, this can't be done for all
> workarounds, but for the easy ones where it can, there's no harm in
> taking advantage of it.

That's OK with me, I guess. What if other libraries (or the user
himself) is making the same hack? If there are no multiple definition
warnings, I have no objections.

> The one change I can see that should be to config.hpp is to detect
> STLport, and if present, turn off BOOST_NO_STDC_NAMESPACE, since
with
> STLport, the boost libraries see the compiler as already conformant
> with regard to ptrdiff_t being in the right namespace. I'm not a
> STLport expert, but I think something like:
>
> #if !defined(__SGI_STL) && defined(__STL_IMPORT_VENDOR_CSTD)
> # define BOOST_NO_STDC_NAMESPACE
> #endif

I don't know what the raw SGI STL does about this, but STLport has
it's own preprocessor symbol, __SGI_STL_PORT.

I don't understand the condition above: how would
__STL_IMPORT_VENDOR_CSTD ever be defined if __SGI_STL_PORT wasn't?

-Dave


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk