C++ -- When recompilation is required
Strictly speaking, you end up in Undefined Behavior land as soon as you do not recompile for any of those reasons.
That said, in practice you might get away with a few of them:
- add a constructor
Might be Ok to use as long as
- it's not the first user-defined constructor to the class
- it's not the copy constructor
- add a data member
This changes the size of instances of the class. Might be Ok for anyone who just uses pointers or references, if you take care to put that data behind all other data, so that the offsets for accessing the other data members do not change. But the exact layout of sub objects in binary is not defined, so you will have to rely on a specific implementation.
- change destructor into virtual
This changes the class' virtual table, so it needs recompilation.
- add an argument with default value to an existing member function
Since default arguments are inserted at the call site, everyone using this needs to recompile. (However, using overloading instead of default arguments might allow you to get away with that.)
Note that any inlined member function could render any of the above wrong, since the code of those is directly embedded (and optimized) in the clients' code.
However, the safest bet would be to just recompile everything. Why is this an issue?
All of them need to recompile all the libraries that use the class. (provided they include the .h file)
Classes are defined in the header file. The header file will be compiled into both the library that implements the class and the code that uses the class. I am assuming that you are taking as a given that you will need to recompile the class implementation after changing the class header file and that the question you are asking is whether you will need to recompile any code that references the class.
The problem that you are describing is one of binary compatibility (BC) and generally follows the following rules:
- Adding non-virtual functions anywhere in the class does not break BC.
- Changing any function definition (adding parameters )will break BC.
- Adding virtual functions anywhere changes the v-table and therefore breaks BC.
- Adding data members will break BC.
- Changing a parameter from non-default to default will not break BC.
- Any changes to inline functions will break BC (inline function should therefore be avoided if BC is important.)
- Changing compiler (or sometimes even compiler versions) will probably break BC unless the compilers adhere strickly to the same ABI.
If BC is a major issue for the platform you are implementing it could well be a good idea to separate out the interface and implementation using the Bridge pattern.
As an aside, the C++ language does not deal with the Application Binary Interface (ABI). If binary compatibility is a major issue, you should probably refer to your platform's ABI specification for more details.
Edit: updated adding data members. This will break BC because more memory will now be needed for the class than before.