Boost logo

Boost :

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2020-12-02 15:36:58

On 12/2/20 5:55 PM, Edward Diener via Boost wrote:
> On 12/2/2020 9:42 AM, Andrey Semashev via Boost wrote:
>> On 12/2/20 5:08 PM, Edward Diener via Boost wrote:
>>> On 12/2/2020 5:12 AM, Andrey Semashev via Boost wrote:
>>>> On 12/2/20 1:21 AM, Edward Diener via Boost wrote:
>>>>> I believe the great majority of Boost libraries attempt to maintain
>>>>> ABI compatibility between releases.
>>>> My impression is the opposite. Boost has never declared backward ABI
>>>> or API compatibility. There's a reason why binary distributions of
>>>> Boost append a version tag that matches Boost version to packages
>>>> and binaries.
>>> Whether Boost declares it or not I do not think Boost libraries
>>> change the API or ABI very often between releases and, if they do,
>>> they will notify the end-user about it.
>> No, not really. Internal changes are often not reflected in the
>> release notes at all, while they may affect ABI.
> If the binary interface between the end-user and a library remains the
> same I do not think changes to some internal structure or internal
> functionality matters. Can you give an example where it does ?

In Boost.Filesystem
directory iterators switched from shared_ptr to intrusive_ptr
internally. This changed the ABI but not API, and this change would not
have been detected by the linker since this change would not affect
library symbols. Even ignoring Boost.Filesystem library, if some part of
user's code is not recompiled with the new library headers, there would
be ABI mismatch and related problems.

This was purely an internal change that does not affect use of the
library, so there was no mention of it in the 1.70 release notes.

I'm pretty sure that actively developed libraries do that sort of
internal changes all the time without worrying that those are
potentially ABI breaking changes.

Boost list run by bdawes at, gregod at, cpdaniel at, john at