Boost logo

Boost :

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:
> . 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.

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
( 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at