Re: The new Boost 17.0.0

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.