From: Ed Brey (brey_at_[hidden])
Date: 2000-06-01 09:42:19
From: "Dave Abrahams" <abrahams_at_[hidden]>
> on 6/1/00 7:18 AM, Mark Rodgers at mark.rodgers_at_[hidden] wrote:
> > What I don't really want to do, is pay the price of having other
> > non-conformant implementations affect the readability of the code
> > and use.
> I really agree, but it's a balancing act I think. A boost library
> be as valuable as the number of people that adopt it.
IMHO, we already achieve this balance with BOOST_NO_STDC_NAMESPACE,
which causes ptrdiff_t to be pulled into namespace std. As Mark
Rogers alluded to, this doesn't step on ground reserved to C++
implementations, since any implementation that doesn't put ptrdiff_t
into namespace std in the first place isn't a C++ implementation to
begin with; it's an implementation of a language similar to C++.
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.
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
in the VC section of config.hpp should work.
Are there other complications regarding ptrdiff_t (and its relatives)
that I'm missing?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk