On 6/6/2014 11:39 AM, John Maddock wrote:
May be it would be better to move boost/mpl/bool.hpp, boost/mpl/bool_fwd.hpp, boost/mpl/integral_c.hpp, mpl/or.hpp, mpl/identity.hpp, mpl/and.hpp into the Core library?
No, a header called boost/mpl/something.hpp will never be part of Core, and neither will a component boost::mpl::something. We might duplicate these as boost/core/something.hpp and boost::core::something, but they will not be quite the same as their mpl counterparts, and will not magically make a module that includes a boost/mpl/ header drop its dependency to MPL.
An option is to implement them into boost::core namespace and inject them into boost::mpl namespace in boost/mpl/. Then each library can break mpl dependencies incluing core headers and namespaces instead of mpl ones. But this is not trivial.
From dependencies standpoint, MPL does not add much, see our earlier exchange [1]. I think value_init can be moved to Core and changed to depend on TypeTraits.Core once it's ready. detail/endian.hpp has been handled already.
Even now, looking at the report [2], the situation is much better than it was before, when we discussed it.
MPL decomposition is also pending, but it's probably better to split it into two modules MPL and MPL.Core, similar to TypeTraits. For many cases dependency on MPL.Core would be enough.
I'm tied of saying this.... but if mpl::bool_ and int_ were moved out of MPL full, either to core, or to some mpl_core, then there's no need to split type_traits anymore.
Indeed I suspect there's a huge amount of obfuscated code inherited from mpl's broken-compiler-workarounds that can now be removed: not only do we not support those compilers any more, but given that they haven't been tested in heaven knows how long they're unlikely to compile *any* of modern Boost anyway.
Based on Stephen Kelly's recommendations I actually removed a bunch of old workarounds in MPL for compilers which we don't support anymore. I even posted about it on this mailing list. But Daniel james objected to this being done for the 'develop' branch of MPL so I posted the change to a remote branch of MPL called 'remotes/origin/mfixes'. Looking through code in MPL, and other long-standing libraries may be similar, the need to keep compiler workarounds in the code for compilers which are obsolete, or do not implement basic parts of even the C++ 98 standard, makes understanding and updating code fairly difficult in many cases. I believe that Boost has a right to say to those who still want to use some of these compilers with Boost that they will have to stick to previous versions. It really becomes difficult for a number of Boost libraries to move forward if they have to continually support poorly conforming compilers. As obvious examples I would not bother trying to support VC++ versions prior to VS2005/VC8 and I would not bother trying to support gcc versions prior to 4.0 etc.