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: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2015-01-07 08:33:00

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.

Currently, in some compilers (like VC7.1 which is the minimum that my 
libraries support)

-> #include <boost/type_traits/aligned_storage.hpp>

generates a ~400KB preprocessed file.

-> #include <boost/type_traits/has_trivial_destructor.hpp>

generates a ~300KB preprocessed file.

-> #include <boost/type_traits/has_nothrow_copy.hpp>

generates a ~300KB preprocessed file.

-> #include <boost/type_traits/is_enum.hpp>

generates a ~100KB preprocessed file.

-> #include <boost/type_traits/is_pod.hpp>

generates a ~300KB preprocessed file.

etc...
On the other hand,

-> #include <boost/move/detail/type_traits.hpp>

leads to only ~30KB of preprocessed code, and that includes all the 
traits Move, Intrusive, Container and Interprocess currently need in the 
compilers those libraries support. The implementation might not be 
correct in all corner cases, but it's what those libraries need.

My opinion is that nobody should be forced to depend on MPL, Exception, 
Move, TypeIndex, StringRef etc. Forward declarations can be used 
whenever possible to avoid header dependencies and tag detection or 
similar techniques could be used to avoid including parts of other 
libraries in TypeTraits.

Maintaining an intrinsics header it's an additional work but I think 
it's worth the effort to improve the usability of some libraries. In 
general, I think that Peter's proposal 
(http://lists.boost.org/Archives/boost/2014/06/213850.php) to simplify 
TypeTraits is the way to go, only an internal bool should be enough. But 
that might break a lot of code, I'm afraid.

Note that we still have interoperability problems between std:: and 
boost:: types (mpl::bool_, boost::integral_constant<bool>, 
std::true_type...) that don't make current boost approach a definitive 
answer to libraries that might want to be compatible with std:: traits. 
boost::integral_constant is not the definitive answer if you want to be 
nice with some standard utilities. A boost::true_type lying in Core, 
that can be constructed from anything that has an internal static 
constant boolean with value true is the key for interoperability between 
boost, standard or custom traits.

> Those libraries are "base", because they are the very common part of Boost
> framework. Not using them is more like a bad decision, reimplementing parts
> of them is an afwull decision. Threating them as base/common/core/main part
> of Boost seems reasonable.

I think the definitive answer is to reduce coupling between those "base" 
libraries, IMHO those "base" libraries are too heavy now. If we can 
reduce that coupling, I'd happily switch back to Boost.TypeTraits or 
just reuse TypeTrait's intrinsics header if that header does not depend 
on MPL and indirect additional dependencies.

Ion