title: How to design a C++ API for binary compatible extensibility
body: <p>I am designing an API for a C++ library which will be distributed in a dll / shared object. The library contains polymorhic classes with virtual functions. I am concerned that if I expose these virtual functions on the DLL API, I cut myself from the possibility of extending the same classes with more virtual functions without breaking binary compatibility with applications built for the previous version of the library.</p>
  
  <p>One option would be to use the <a href="http://en.wikipedia.org/wiki/Opaque_pointer" rel="noreferrer">PImpl</a> idiom to hide all the classes having virtual functions, but that also seem to have it's limitations: this way applications lose the possibility of subclassing the classes of the library and overriding the virtual methods.</p>
  
  <p>How would you design a API class which can be subclassed in an application, without losing the possibility to extend the API with (not abstract) virtual methods in a new version of the dll while staying backward binary compatible?</p>
  
  <p>Update: the target platforms for the library are windows/msvc and linux/gcc.</p>