From: Edward Diener (eldiener_at_[hidden])
Date: 2020-12-03 02:20:20
On 12/2/2020 6:00 PM, Gavin Lambert via Boost wrote:
> On 3/12/2020 3:55 am, Edward Diener wrote:
>> 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 ?
> Any change to members (of any kind, including private) affects the
> layout and size of a class, which is a breaking change to the class ABI.
OK, I understand. I did not mean to sound dumb. Of course you are right.
> This causes all manner of subtle ODR problems as soon as you try to mix
> a translation unit compiled with the old class definition with one
> compiled with the new class definition, even if at first glance it seems
> like the consuming code never directly accesses those members.
> Defaulted constructors/destructors/operators and inlined methods of any
> kind are the biggest culprits of issues, but it's not limited to those.
> And only if you're very lucky will you see a linker error about a
> missing symbol.Â It's most likely that there will be no errors at all
> until something crashes or subtly misbehaves at runtime.
> (This is fundamentally an issue with C++ itself, where it favours
> performance over robustness, which is at the heart of the ODR.)
> And yes, historically Boost has made absolutely no guarantees of ABI
> stability whatsoever between releases (read: assume it will always break
> ABI), although it may sometimes work by coincidence simply due to
> changes being relatively rare in stable libraries.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk