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. 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.