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

On 01/07/2015 07:22 AM, Beman Dawes wrote:

On Wed, Jan 7, 2015 at 8:33 AM, Ion Gaztañaga 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... . 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 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