ABI compatibility of interfaces (abstract classes) with other virtual changes

Does the ABI of the view of a class remain stable even if other changes, involving virtuals, are made in the derived class?

That is, say I have an interface InterfaceA (abstract class with many pure virtual functions) and a class DerivedB that inherits from it. I write a library that has a function taking a InterfaceA *. What I want to know is whether the interface remains binary compatible so long as the interface itself does not change.

Clear, if I modify InterfaceA I do not expect the code to be binary 开发者_C百科compatible. However, what if I just modify DerivedB, say I inherit more interfaces or add other virtual functions. In the most extreme say I multiply inherit from another class which defines InterfaceA. Does InterfaceA remain binary compatible despite all these changes?

My assumption, and experience, to now is that yes it is compatible. I'm just looking for confirmation of this (or refutation if not compatible).

Note: I don't care about dynamic typing, or other casting, I only care about the interface functions themselves.

Also Note: Assume the compiler versions being used are ABI stable as whole -- no major version changes.

Yes, as long as the name, arguments, and order of virtual functions in InterfaceA does not change, it will stay binary compatible. Note that this allows you to add functions at the end of the class declaration.

(It is possible this is not explicitly guaranteed by the C++ spec, but COM relies on this so the big C++ compilers will work this way.)

Assuming you're not using DerivedB across the ABI boundary, you should be able to do just about anything you want to it. The pure virtual class (DerivedA) is what matters most and if you're not changing it then you're correct - anything using that pointer to InterfaceA won't have any problems crossing the boundary.

In fact, you can even add a function to the end of InterfaceA as long as it is a leaf interface (ie no other interfaces inherit from it) and the function isn't an overload of another function. Of course it needs to follow the same "ABI rules" as your other functions - ie the parameter types must be primitive types or pointers to other interfaces, etc. If you have a versioning system, your app can check the plugin's version and determine whether or not the new function can be safely called - thus adding functionality for newer plugins but old plugins compiled before the change will still work. Pretty cool!