Re: config/conformance issue

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