Re: [boost] The new Boost 17.0.0

On 12/1/2020 4:39 PM, Antony Polukhin via Boost wrote:

On Wed, Dec 2, 2020, 00:22 Edward Diener via Boost wrote:

...

On 12/1/2020 2:44 PM, Antony Polukhin via Boost wrote:

...

On Fri, Nov 27, 2020, 15:54 Edward Diener via Boost

...

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 ?

More or less. Users will use the standard libraries anyway, adding Boost libraries that duplicate the functionality increase the size of translation unit. If you have no standard alternative - you use Boost, you have no choice.

I am not against C++98/C++03 libraries being upgraded to C++11 in order to use C++ standard library equivalents to Boost types. Nor am I against a separate C++11 library of a current C++98/C++03 library being added to Boost which uses C++ standard library equivalents to Boost types and in all other respects is the same as the original library. But the latter solution does require extra maintenance and who is going to do that ?

...

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 ?

Not any, but many.

I believe the great majority of Boost libraries attempt to maintain ABI compatibility between releases. But just like with compilers it is not always possible between releases.