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

From: John Maddock (jm_at_[hidden])
Date: 2003-02-11 06:54:45

> 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.

I think I like that - do you want to put together the headers?
 
> 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.

Agreed, I guess it depends on how many patch headers we end up with.

John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/index.htm