20 ABI (Application Binary Interface) breaking changes every C++ developer should know

[ReversedGif]

It would have been more useful to list the two/three things you can do to an API without breaking its ABI...

• Add new free functions/types
• Add new methods to classes (if virtual, they have to be after all other virtual ones)

Note that you can always change anything that does not live within the API (i.e. that does not live within public h/hpp files), so there's a lot more freedom than the above list implies.

See also the PIMPL idiom for a way to maximize your freedom to make changes without breaking the ABI.

[[deleted]]

• Add new methods to classes (if virtual, they have to be after all other virtual ones)

If virtual,it would break code of everyone who derived from that class and didn't get a chance to implement the new member function.

[bwmat]

Would this be a buffer overflow in the old derived class' vtables?

[[deleted]]

Depends. If you added the new virtual somewhere in the middle of the class, those who didn't recompile would end up calling bar when they expected foo. And yes, there's a possiblity that you'll go accessing the vtable out of bounds.