From: Edward Diener (eldiener_at_[hidden])
Date: 2020-12-03 02:13:25
On 12/2/2020 10:36 AM, Andrey Semashev via Boost wrote:
> 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.
But if the end-user's code does not reference the internal directory
iterators why does the end-user code need to recompile itself to match
the change to the internal ABI ?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk