From: Edward Diener (eldiener_at_[hidden])
Date: 2020-12-01 21:21:52
On 12/1/2020 2:44 PM, Antony Polukhin via Boost wrote:
> On Fri, Nov 27, 2020, 15:54 Edward Diener via Boost <boost_at_[hidden]>
>> On 11/27/2020 3:58 AM, Antony Polukhin via Boost wrote:
>>> == 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
>>> New companies (startups) also avoid Boost:
>>> * "We are using C++17, we do not want legacy libraries with C++98
>> 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
> 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.
So if you use in a C++17 project a Boost library which supports
C++98/C++03 you have huge translation units but if you use a Boost
library which supports C++11 on up or if you use C++ standard libraries
which often depend on each other you never have huge translation units.
Is that what you are saying ?
>> * 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.
Of course if you use the mongo library, whatever it is, with the C++
standard library it automatically works with whatever the latest C++
standard library is installed but if you use mongo with Boost it only
works with Boost 1.45 and not the latest Boost. And this is Boost's
fault no doubt !
> 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
Are you saying that Boost is not ABI compatible between releases but any
compiler's C++ standard library is always ABI compatible between releases ?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk