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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
