Lo standard non riguarda la compatibilità binaria. Riguarda però le classi e "cambiando" la definizione di una classe da una unità di traduzione a un'altra effettivamente invocate un comportamento indefinito.
La maggior parte dei compilatori consente una serie di modifiche senza la necessità di ricompilazione, tuttavia l'elenco è piccolo ... e per questo direi che potrebbe non essere possibile, a seconda della conoscenza a priori del derivato classi.
Il problema che presumo risiede nell'ottimizzazione che i compilatori normalmente eseguono sui tavoli virtuali.
Quando si crea una classe con funzioni virtuali, si ottiene una tabella virtuale che assomiglia così:
// B virtual table
0 - Offset to complete object
1 - RTTI
2 - func0
3 - func1
...
Al fine di guadagnare un po 'di spazio, la classe derivata proprie funzioni virtuali sono di solito "aggiunto":
// D virtual table
Same as B
N+3 - func(N+1)
N+4 - func(N+2)
questo modo un oggetto D
ha soltanto un puntatore virtuale, che può essere usata come tale anche quando il tipo è (staticamente) un B
(tramite puntatore o un riferimento).
Tuttavia, se si dovesse estendere B
senza ricompilare D
, allora sarebbe incidente semplicemente, dal momento che quando si chiama la funzione N+1
di B
si sarebbe invece chiamare la funzione di D
N+1
che probabilmente non hanno nemmeno gli stessi argomenti. .. oups!
Si può fare, tuttavia, se si utilizza che nessuna classe derivata aggiunga alcuna funzione virtuale propria.
fonte
2011-04-19 08:52:36
Desidero estendere l'interfaccia della libreria. Se esiste un altro modo per ottenere ciò senza modificare le firme delle funzioni API accettando la classe della libreria principale come argomento, mi piacerebbe saperlo anche io. – Basilevs
c'è un documento interessante del progetto KDE: [Problemi di compatibilità binaria con C++] (http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B). Link a due altri documenti che potresti essere interessato a leggere. – Mat