I was looking into creation of DLL's using C++ lately and stumbled by accident into the discussion of "Abstract Base Classes vs. Pimpl Idiom" when it comes to ABI compatibility. I'm pretty new to dealing with DLLs so please be patient if I get a term/concept wrong. Here's my story:
I've read in this article here over at CodeProject.com where the author states that using an abstract interface is the way to go.
To summarize: You have an abstract base class class IFoo
, a factory method extern "C" __declspec(dllexport/dllimport) IFoo* createFoo();
and an actual implementation class FooImpl
of the IFoo
interface which is what is actually instantiated and returned by createFoo()
.
So far so good.
Now I found some people argue that only the Pimpl-Idiom could preserve ABI compatibility (What's is the point of PImpl pattern while we can use interface for the same purpose in C++?, Pimpl idiom vs Pure virtual class interface ) and I'm a bit confused:
The way I understand pimpl: You have a class Bar
holding a pointer to class BarImpl
which contains all implementation detail.
My questions:
If I only change the internal workings in both cases (change either
class FooImpl
orclass BarImpl
) the ABI of code "facing the user" in both cases does not change, or does it ?On the other hand both approaches break clearly ABI compatibility if I make changes to
class Foo
orclass Bar
, right ?In case my assumptions of ABI compatibility using abstract base classes are wrong. Do I have to use a mixture of abstract base classes in DLLs to truly keep ABI compatible if I only perform changes to internal stuff of the libraries code ?
I hope I could clearly formulate what's unclear to me ;)
EDIT: By "changing internals" I also refer to adding/removing of members/methods in the implementation classes FooImpl
and BarImpl
.