Re: The new Boost 17.0.0

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 
> (https://github.com/boostorg/filesystem/commit/498a090b531833355ea27cea94d0440c432f8afc) 
> 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 ?