Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at