Boost logo

Boost :

From: Daniele Lupo (jepessen_at_[hidden])
Date: 2024-04-12 14:18:31


On 11/04/2024 16:27, Artyom Beilis via Boost wrote:
> I wish Boost was nearly as compatible as Qt. Seriously.
>
> Qt has very good API compatibility between major releases and binary
> compatibility across entire major version. Boost is horrible in that.
>
> It was one of the reasons I barely use Boost nowadays because
> you can never know when it breaks something.
>
> I have experienced so many issues with compilation against different
> versions of boost (not in my code) that it is really a big problem.
>
> Qt does amazing job in keeping ABI stable, boost can't even have barly
> stable API.
>
> Artyom

I don't instead. Forcing ABI compatibility created in C++ standard
different issues, for example the performances of std::regex, or the
existence of std::jthread.

I mean, ABI compatibility is good, but in my opinion should be no more
important that API compatibility or performance. If I'm developing a
project, I use a specific version of Boost. If for some reason I need to
update it, I simply rebuild the project; if API is compatible I need
only to build the project without changing code, and it works, I don't
care about ABI.

Qt obtains the ABI compatility not because the layout of classes remain
the same, but due to PIMPL idiom, that adds a lot of indirections,
everywhere. This can be good for widgets, where the performance loss is
negligible, but in some cases where performance is important, PIMPL
impact can be noticeable, even if not important. I prefer performances
over ABI compatibility in this case. Also, the compatilibity forces to
do not update or refactor the interface of classes, making very big
classes that can be refactored easily (I mean, look how many things
QString does for example).

My idea is that the library compatibility between different versions
should be:

- ABI compatiliby between patch versions (1.84.0 -> 1.84.1) - API
compatility between minor versions (1.84.0 -> 1.85.0) - API can break
between major versions (1.84.0 -> 2.0.0)

This can ensure a good tradeoff between improvement of a
library/framework and compatibility with existing code in my opinion.

Daniele


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk