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