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/498a090b531833355ea27cea94d044...) 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 ?