On Fri, Nov 27, 2020, 15:54 Edward Diener via Boost
On 11/27/2020 3:58 AM, Antony Polukhin via Boost wrote:
Hi,
== The problem. TL;DR: we are having huge troubles with usability and popularity!
Quite a lot of companies forbid using Boost because: * it provides vocabulary types, that should be the same across the whole project (like shared_ptr, filesystem::path or optional). Otherwise it's hard to combine different APIs * it is huge, in consists of legacy on more than a half, with a lot of dependencies between libraries. This is extremely painful for big companies, because there's no efficient distributed build system. Each company invents it's own and/or tries to minimize headers by all means.
New companies (startups) also avoid Boost: * "We are using C++17, we do not want legacy libraries with C++98 support"
If a library provides support for C++98/2003 but also works perfectly fine using C++17, please explain to me what is wrong with using that library when compiling for C++17 ? Thank you !
For example, that library may use boost/type_traits.hpp and boost/mpl/*. Those headers include a bunch of text and variadic templates emulation, and compile times getting drastically worse. Another example: library that uses boost/optional.hpp includes ~500kB of code. To make things funnier, ln some standard libraries inclusion of boost/optional.hpp leads to inclusion of <optiknal>, so removing the dependency drops 500kb of text from each translation unit. Final example: library work in c++98 and it almost does not depend on other Boost libraries. Great! It's a perfect candidate for Boost17. Nothing wrong in c++98 support, the problem is in the dependencies and huge translation units to compile.
* hard to upgrade, because symbols are not versioned
Versioned symbols ?
If you are using a system package that relies on Boost, then you can not upgrade Boost. For example mongo library uses Boost 1.45 and you wish to use Boost 1.74 => you've got problems. Linker may merge not ABI compatible Boost symbols, leading to breakages. More specifically, the layout of Boost.Variant changed multiple times since 1.45, but the signature of the boost::apply_visitor function did not change. As a result you get ODR-violation.