Re: [boost] Road to low-quality-code is paved with good intentions of dropping dependencies

Subject: Re: [boost] Road to low-quality-code is paved with good intentions of dropping dependencies
From: Michael Caisse (mcaisse-lists_at_[hidden])
Date: 2015-01-07 14:33:04

On 01/07/2015 07:22 AM, Beman Dawes wrote:
> On Wed, Jan 7, 2015 at 8:33 AM, Ion Gaztañaga <igaztanaga_at_[hidden]> wrote:
>> El 07/01/2015 a las 10:49, Antony Polukhin escribió:
>>>
>>> Hi all,
>>>
>>> I've been looking through the latest changes to drop dependencies. Stuff
>>> that I saw is very frightening.
>>>
>>> For example:
>>>
>>> https://github.com/boostorg/move/blob/develop/include/boost/move/detail/type_traits.hpp
>>> . Every boost release some issues are fixed in intrinsics of TypeTraits
>>> and
>>> is_move_* is_nothrow_* traits. Copy-pasting code from TypeTraits feels
>>> like
>>> loading a gun and pointing it on own foot.
>>
>>
>> I really don't agree. I've measured the code bloat that TypeTraits and other
>> "low-level" libraries were bringing to some libraries and it was very
>> noticeable. I would like to depend only on TypeTraits but that's impossible,
>> it brings MPL, Preprocessor, etc. Including boost/container/vector.hpp was
>> bringing MB of preprocessed lines, comparing it to 200KB of preprocessed
>> code for <vector> and several users were complaining about compilation
>> times. Compilation times have improved with the dependency removal. I've
>> contributed a little bit to Boost.TypeTraits and I'd like to use it, but
>> only if we can make Boost.TypeTraits depend only on Config/Predef.
> 
> For all the type traits that are now supported by the standard library
> in use, it might be nice if #include
> <boost/type_traits/std/some_trait.hpp> brought in the standard library
> version. So eventually the many boost libraries that use only type
> traits that have been standardized would have no dependencies on the
> actual boost implementations.
> 

This worries me. I have had mixed results with type traits specifically
and the behaviour of the Boost flavour versus the std flavour from
various vendors. I don't recall the specifics right now except to recall
that the std::is_pod in MSVC produced different results than gcc and Boost.

I would rather see these choices be more implicit. I am not a fan of
auto-selecting between the vendor version or the Boost version for any
library. It creates more surprises than I like.

michael

-- 
Michael Caisse
ciere consulting
ciere.com