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

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. Currently, in some compilers (like VC7.1 which is the minimum that my libraries support) -> #include generates a ~400KB preprocessed file. -> #include generates a ~300KB preprocessed file. -> #include generates a ~300KB preprocessed file. -> #include generates a ~100KB preprocessed file. -> #include generates a ~300KB preprocessed file. etc... On the other hand, -> #include 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