Re: Technical Excellence?

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