Tout d'abord, je vous réfère à un compilateur Windows Environment et VC ++.
Ce que je veux pouvoir faire est de reconstruire une DLL VC ++ et de maintenir la compatibilité avec un EXE qui a déjà été lié à la lib sans devoir reconstruire l'EXE ni charger la DLL de manière dynamique à l'aide de LoadLibrary. En d'autres termes, existe-t-il un moyen d'ajouter des cours et des méthodes à une DLL (mais non supprimé) et d'assurer que les points d'entrée existants restent les mêmes?
4 Réponses :
Tant que vous n'ajoutez aucun symbole exporté, les ordinaux ne changeront pas. Si vous ajoutez des symboles exportés via le mécanisme standard de Dllexport, cela va être difficile à contrôler. Si vous utilisez l'ancien fichier de symbole de style .xpf, vous pourrez peut-être contrôler la commande des symboles dans la libère (bien que je ne sache pas cela à coup sûr - cela pourrait toujours les réorganiser cependant), mais c'est délicat de faire C ++ symboles de cette façon.
Si vous exportez les fonctions de l'utilisation d'un fichier DEF et spécifiez manuellement les ordinaux, vous devriez être capable de l'accomplir.
référence
http://msdn.microsoft.com/fr -us / bibliothèque / d91k01sh (vs.80) .aspx
J'aimerais ajouter la référence MSDN.MicRosoft.com /en-us/Library/900axts6(vs.80).aspx Il est juste un clic à l'écart de l'hyperlien ci-dessus et discute des raisons d'utiliser des fichiers def et des avantages et des inconvénients.
Voici les liens de travail mentionnés dans la réponse et dans le commentaire, respectivement: docs.microsoft.com/en-us/cpp/build/... et docs.microsoft.com/en-us/cpp/build/...
Je pense que les ordonnances sont rarement utilisées pour résoudre les importations de la DLL, je pense que vous devez utiliser des fichiers .def pour obtenir le lien pour les utiliser. Ainsi, tant que vous ne modifiez pas les noms ou les signatures des fonctions exportées, le .exe devrait fonctionner simplement bien.
Cela dépend de la manière dont votre exe a utilisé les classes de la DLL. L'ajout de nouvelles classes ne doit pas affecter les points d'entrée existants. En plus de cela, cependant, les éléments suivants affecteront la taille et / ou la disposition de l'objet, et comme ce sera un changement de client-rupture (note que c'est techniquement spécifique à la VC, mais la plupart d'entre eux s'appliquent à toute mise en œuvre SANE): < / p>
Je pense que c'est une bonne réponse, mais je changerais une chose: changer les méthodes virtuelles dans une classe de quelque manière que ce soit serait suspect. Je ne pense pas que vous puissiez compter sur la tablette pour avoir les fonctions virtuelles dans la même commande que celle indiquée dans le fichier source.
En VC au moins, vous pouvez compter sur cela - il s'agit de la condition préalable au support COM (qui nécessite une commande de la table équitable définie).
Grande réponse Pavel, je me demande simplement si vous pouviez ajouter des références afin de soutenir vos affirmations. Merci!
@David, c'est surtout la connaissance de 1) Compréhension des techniques de mise en œuvre typiques (VTABLES ETC) et 2) Expérience. La principale source ici serait la spécification ABI pour un compilateur particulier. En ce qui concerne les sources secondaires, KDE DOCS a une liste similaire à la mine ici: TechBase.kde.org/policies/binary_compatibility_issues_with_c ++ - et la recherche générale de la «compatibilité binaire C ++» devrait donner quelques résultats plus pertinents.