Re: [boost] New dependency report

Subject: Re: [boost] New dependency report
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-06-06 16:41:05

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.