On Wed, Dec 2, 2020, 00:22 Edward Diener via Boost
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.
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.