Re: The new Boost 17.0.0

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

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
> ODR-violation.

Are you saying that Boost is not ABI compatible between releases but any 
compiler's C++ standard library is always ABI compatible between releases ?