Si j'ai plusieurs bibliothèques liées au C ++ liées à C ++ en C ++, est-il possible pour eux de partager des objets de classe (passez à des fonctions) s'ils ont été compilés avec des valeurs différentes d'informations de temps d'exécution activées / désactivées (RTTI) ?
- Modifier: Merci pour les réponses, les choses spécifiques que j'étais inquiets était 1. Activation de la RTTI modifier le comportement de la taille de Static (types non polymorphes)?
et, 2. Si je crée une classe dans une bibliothèque activée RTTI et transmettez-la à une autre bibliothèque activée non RTTI, les méthodes virtuelles fonctionnent correctement. (et vice versa)
et enfin 3. Si je crée une classe dans une bibliothèque compatible RTTI, je m'attends à pouvoir utiliser dynamic_cast avec elle, si je passe cet objet à une bibliothèque activée non-RTTI, puis-je toujours l'utiliser sur que Objet. ... Je ne supposerais pas, et cela semble être une mauvaise idée de toute façon ... je suis juste curieux.
3 Réponses :
Cela dépend de quel compilateur C ++ spécifique dont vous parlez - je n'ai aucune expérience de plateformes multiples récentes avec C ++ (mon travail C ++ ces dernières années a été presque exclusivement avec C ++ sur Linux), mais il y a quelques années J'aurais parié que GCC vous aurait laissé échapper avec un peu de malcegenation, visuelle C ++ "Pas de moyen", d'autres compilateurs quelque peu au milieu ...! -)
Tant que les classes partagées ne sont pas polymorphes (i.e, ils ne contiennent pas de fonctions virtuelles), ce ne sera pas un problème. Mais vous ne pourrez pas utiliser dynamic_cast, typeid et exceptions avec RTTI Désactivé.
Différents drapeaux peuvent entraîner différentes structures dans les structures, entraînant ainsi des objets incompatibles entre les bibliothèques.
Comment les informations RTTI sont stockées sont un détail de mise en œuvre et ne sont donc pas portables entre différents compilateurs.
La plupart des compilateurs ne garantissent même pas que les objets compilés avec différents drapeaux utiliseront le même ABI pour leurs méthodes. Ceci est le plus clairement montré avec les bibliothèques de libération et de débogage, mais d'autres drapeaux peuvent également causer des différences.
Non seulement l'ABI pour les fonctions / méthodes change, mais les drapeaux peuvent affecter le rembourrage utilisé par le compilateur entre éléments dans des structures ainsi, même des objets sans méthodes virtuelles peuvent être incompatibles lors de la compilation avec des drapeaux différents.
Lorsque vous utilisez la plupart des identifiants, vous pouvez voir les effets. Les fichiers binaires de débogage / de sortie sont intégrés à des annuaires distincts et uniquement liés au même type de binaire (également toute construction définie par l'utilisateur sera intégré à un répertoire unique séparé comme une différence de drapeaux peut provoquer des incompatibilités). Si vous modifiez certains indicateurs sur une construction, tout le projet est généralement obligé de ré-construire.
Excellents points qu'aucun autre ne pensait ici, en particulier les problèmes concernant le rembourrage en fonction des paramètres du compilateur.
@Loki Astari: Cela implique-t-il si j'utilise un objet d'un fichier .so ou .dll (compilé avec RTTI désactivé), je ne pourrais ni utiliser dynamic_cast ni typeid pour cet objet. Ou pire, l'ABI n'était pas correct afin que les programmes soient incompatibles (peut-être crash, etc.).
@ Shao-chuanwang: potentiellement. Tout dépend de votre compilateur. Pour être en sécurité, tous les objets doivent être compilés avec exactement les mêmes drapeaux.