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