El estándar no se refiere a la compatibilidad binaria. Sin embargo, le preocupan las clases y, al "cambiar" la definición de una clase de una unidad de traducción a otra, invoca un comportamiento indefinido.
La mayoría de los compiladores permiten una serie de cambios sin la necesidad de recompilación, sin embargo, la lista es pequeña ... y para este diría que podría no ser posible, dependiendo del conocimiento a priori del derivado clases.
El problema que preveo radica en la optimización que los compiladores suelen llevar a cabo en las tablas virtuales.
Al crear una clase con funciones virtuales, se obtiene una tabla virtual que se ve así:
// B virtual table
0 - Offset to complete object
1 - RTTI
2 - func0
3 - func1
...
Con el fin de ganar un poco de espacio, las propias funciones virtuales de clase derivada se suele "anexado":
// D virtual table
Same as B
N+3 - func(N+1)
N+4 - func(N+2)
esta manera un objeto de D
sólo tiene un puntero virtual, que puede ser utilizado como tal, incluso cuando el tipo es (estáticamente) un B
(a través de puntero o de referencia).
Sin embargo, si tuviera que extender B
sin recompilar D
, entonces sería accidente simplemente, ya que cuando se llama a la función N+1
de B
que tendría lugar llamar a la función N+1
de D
que probablemente ni siquiera tienen los mismos argumentos. .. oups!
Se puede hacer, sin embargo, si sabe que ninguna clase derivada agrega ninguna función virtual propia.
Quiero ampliar la interfaz de la biblioteca. Si hay otra forma de lograr esto sin cambiar las firmas de las funciones de API que aceptan la clase de biblioteca principal como argumento, me gustaría saberlo también. – Basilevs
hay un documento interesante del proyecto de KDE: [Problemas de compatibilidad binaria con C++] (http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B). Enlaces a otros dos documentos que quizás le interese leer. – Mat