仅使用基类指针时修改私有派生类是否会破坏ABI？

Great question—this is a common point of confusion when working with interface-based polymorphism in C++, especially in dynamic library scenarios. Let's break down the answer clearly:

Core Conclusion #

No, modifying private members of your derived class B (adding, removing, or adjusting private data/methods) will NOT break the ABI, and external libraries that only depend on base class A do NOT need to be recompiled.

Why This Works #

Let's dive into the mechanics:

• External code only interacts with base class A's ABI: All external code holds pointers to A* and only calls methods declared in A. Calls to virtual methods are routed through A's vtable (virtual function table). As long as A's public interface stays unchanged—meaning the signatures, order, and visibility of its virtual/non-virtual methods, plus any public data members, are the same—A's vtable layout remains stable. External code doesn't care about anything beyond this.
• B's private members are implementation details: Private members of B are completely invisible to code that only knows about A. Adding a private data member changes the size of B's object, but since external code never allocates B directly (it only receives A* from your library), this size change has zero impact on their memory management. Similarly, modifying or adding private methods doesn't alter the vtable structure—vtables only include public/protected virtual methods declared in the base class (and their matching overrides in derived classes).
• Dynamic loading (dlopen()/dlsym()) reinforces this: When external libraries load your .so dynamically, they only resolve symbols related to A (like factory functions that return A*, or vtable entries for A's virtual methods). Since B's implementation details aren't exposed in those symbols, changing B won't break symbol resolution for external code.

Quick Comparison to PIMPL #

You mentioned the PIMPL idiom, and this interface-base/derived-implementation pattern aligns with PIMPL's core goal: isolating implementation changes from the public interface. PIMPL uses a forward-declared implementation class pointer inside the interface class, while this pattern uses a base class pointer to a derived implementation. Both approaches shield external code from implementation-level changes, preserving ABI stability.

A Caveat to Watch For #

The only time you'd run into issues is if you accidentally modify the signature of a virtual method in B that's supposed to override a method in A. For example, changing void B::doSomething() to void B::doSomething(int) would mean B no longer overrides A's doSomething()—but this is a logical bug, not an ABI break. External code would still call A's version (if it has a default implementation) or trigger undefined behavior if A's method is pure virtual, but the ABI itself remains intact.

内容的提问来源于stack exchange，提问作者thefunkyjunky