Are there tools to check whether changes to a C++ class will break a previous version of that class?

Question

If you've been programming in C++ for a while, you probably ran a program that crashed "for no obvious reason" to find out that the ABI of the library was not compatible anymore and all you had to do was recompile the software against the new version of the library.

The reason the ABI breaks are multiple: change in virtual table, adding/removing constructors, destructor, or variable members...

What I'm wondering is this: is there a tool that can be used to compare two class definitions (old version and current version) and tell me whether they are ABI compatible or not.

This would be useful to determine the version of my project (i.e. if the ABI changed, I was to go from 1.2.7 to 1.3.0, if the ABI did not change, I just go to 1.2.8).

Many people who program in C++ have had this problem. A good example is Qt which clearly states that patches will not break binary compatibility (although once in a while they make a mistake, but generally, their code is quite solid).

http://qt-project.org/wiki/Qt-Version-Compatibility
http://qt-project.org/faq/answer/is_qt_binary_compatible

However, Qt has staff that can spend time in verifying (all manually?) that the public classes have not changed in a way that would break compatibility. I couldn't say as much of many much smaller C++ projects.

Answer 1

On Linux there is an abi-compliance-checker tool. It can be used to verify backward binary compatibility of your C++ library. See sample reports of the tool for the Qt library: http://abi-laboratory.pro/tracker/timeline/qt/

You need to compile debug version of your library with addition -g -Og options and dump ABI of your library with the help of the abi-dumper tool. And then compare two ABI dumps of different versions to generate ABI changes report.

Answer 2

Formally, if you've changed any token in the class definition, they're not compatible. Otherwise... I don't know of any tool, since most people wouldn't accept the risk if they've changed anything. And since most people will be using make or something similar, anytime anything changes in the header (including correcting a misspelling in a comment), they will automatically recompile all of the sources which include the header, directly or indirectly.

The only problem comes if you've been playing around with the file timestamps. And the answer to that is: don't do it.

Finally, for managing versions, I change the version (visible outside my own build structures) anytime I change anything which might change the interface. And I mangle the version number into the library namespace, so you can't link code with the wrong version of the library. But this is really only necessary if you're delivering the library and headers to other people. (And probably not even then—most programmers I know will automatically do a clean build whenever they upgrade any of the libraries they're using.)