[boost] Re: Borland specific defects : new config defines?

From: Alisdair Meredith (alisdair.meredith_at_[hidden])
Date: 2003-02-07 15:43:44

John Maddock wrote:

> I guess we could boilerplate this and just dump it in the config system, but
> that would mean that <boost/config.hpp> would end up including just about
> all the std headers for this compiler.  A bit heavyweight if you just want
> to use scoped_ptr or something :-(

> Any other ideas?

We could boilerplate each affected standard header, and whenever that
header is included add
#if defined( BOOST_WORKAROUND_BROKEN_BORLAND_STL_NAMESPACE )
#include "boost/[patches]/[broken_header]"
#endif

Of course this moves tbe problem onto the library-maintainer, but avoids
the hyper-include.

Taking this one stage further, we could never directly include the std
file but always call the [patch] version which by default is a
pass-through to the standard header.  I'm not comfortable with this
approach as I would rather see a 'clean' include tree for a conformant
compiler.  Also, I'm not sure if any current compilers perform
optimisations for std includes, but I believe standard is phrased to
allow such implementations.

A middle ground fix might be to define BOOST_BROKEN_STD_INCLUDES if any
standard include is known to be broken for a given compiler (to be
arranged in config) and go with plan B if this is defined or simply the
standard headers otherwise.  This would include as a sub-case the
current boost-supplied implementations for all the <c*> headers.  The
[patch] header would test for each given sub-case, maintaining all
defect-testing in a single place.  Conformant compilers don't notice the
difference.  There is a boiler-plate application for all standard
headers so library authors don't need to think about issues, just follow
the convention.

It's still a bit heavyweight, especially if it is only to fix a single
compiler.  But if this casts a wider net and drags in a couple more, it
may be worth considering.

-- 
AlisdairM