Forward compatibility with abstract classes

[helios]

I just read something that I'm pretty sure is incorrect, but I wanted to make a sanity check.

Suppose you have an abstract class Base that defines an interface of some sort, and you write code that uses instances of Base exclusively through that interface. You compile this code into a static library for reuse. The static library is included in various independent programs that all implement independent concrete subhierarchies of Base. Ignoring the usual C++ ABI issues across compilers and compiler versions, all those programs should be able to use the same version of that static library without having to recompile it, no matter what data members they each add to their own subclasses, right?

[AbstractionAnon]

all those programs should be able to use the same version of that static library without having to recompile it, no matter what data members they each add to their own subclasses, right?

That's correct.

[malibor]

Did you mean recompiling as said or relinking?
You don't have to recompile but a user does need to relink for modifications to apply.

Usual issues known with a DLL's don't apply to static lib.
As long as interface doesn't change there is no need to recompile, just relink.

[dutch]

Did you mean recompiling as said or relinking?

Obviously he means recompile, as in will the static library itself need to be recompiled. It would seem not, but the very fact that someone with his level of experience would ask suggests that there may be more to it than I realize. A more concrete example might help.

[helios]

Great, that's what I thought. Just wanted to check with someone else in case I was overlooking something.
FYI, this was in the context of comparing pimpl to a polymorphic interface. This person was comparing the advantages and disadvantages of each and specifically mentioned that adding data members to subclasses changed the memory layout and thus would imply recompiling users of the interface (strictly of the interface and not of its subclasses).

[keskiverto]

Example with four translation units:

class Base {
  virtual int method() = 0;
}

Neither this definition nor the implementation changes. Therefore, its object file remains valid.

#include "Base.h"

int user( Base* obj ) {
  return obj->method();
}

Nothing in this translation unit changes either. Therefore, its object file remains valid.

#include "Base.h"

class Derived : Base {
  virtual int method();
  // some change here
}

Since definition (and implementation?) does change, this unit must recompile.

#include "Derived.h"

Base* factory() {
  return new Derived;
}

This unit must recompile because definition of Derived has changed.


If all of the above were in one project, then make would not recompile the first two as long as you don't clean out the object files.

Since the non-changing object files are packaged into library, you don't clean them out and hence have no need (nor means?) to recompiled them.


Does it really matter whether the library is static or dynamically linked in this context?