Discussion :

[guillaume07]

Bonjour,

Admettons que l'on vienne modifier le code d'une dll utilisé par un .exe
Je me demandais comment le .exe référencer les fonctions ou classe de la .dll..
Est ce une table en début de dll répertoriant les adresses de début du code des différentes fonctions , permettant ainsi à une fonction d'être modifié (disons son code pas sa signature), tout en garantissant que "le point d'entré" vers cette fonction depuis le .exe reste inchangé , où si au contraire une recompilation du .exe est indispensable

Désolé si pas clair ou phrase longue

Merci.

j'aurais tendance à penser que non ne serait-ce que de part l'existence de système de e plug in etc, mais j'aimerais en avoir confirmation et/ou précision etc, notamment en terme d'ABI

[guillaume07]

99% de la réponse est là
http://www.codeproject.com/KB/cpp/ho...MatureApproach

je laisse le thread ouvert ou cas où certain verrais un commentaire pertinent à faire

Typiquement j'ai du mal à comprendre précisément le problème engendré par l’utilisation de plusieurs version de la CRT

[koala01]

Salut,

Tant que tu ne fais que changer le code du corps des fonctions, mais que tu garde le même compilateur et les mêmes signatures (ou que tu rajoute de nouvelles fonctions), tu n'aura aucun problème, hormis le fait éventuel que ton "ancien" exécutable n'utilisera pas les "nouvelles" fonctions.

La localisation des adresses auxquelles commencent les différentes fonctions se fait, en effet, de manière dynamique, en fonction de l'endroit en mémoire où la dll sera effectivement chargée.

Par contre, il faut savoir que, contrairement à ce qui se fait en C, il n'existe (pour l'instant du moins) ni ABI ni convention d'appel, ni mangling convention (je ne connais pas encore de traduction satisfaisante pour ce terme, mais c'est la convention qui permet d'identifier de manière unique et non ambigüe une fonction particulière parmi ses éventuelles surcharges et / ou parmi les différentes portées ) standard en C++.

On ne peut donc apporter aucune certitude quant au fait que deux compilateurs différents respecteront les mêmes conventions, même lorsqu'ils créent des exécutables pour une même cible.

Mais cela va encore plus loin: il n'y a aucune garantie quant au fait qu'une version donnée d'un compilateur utilisera les même conventions que sa version précédente ou que sa version suivante

Ce n'est donc pas à proprement parler un problème de CRT (Common Run Time) utilisée, mais plus un problème lié aux symboles utilisés pour représenter et / ou rechercher les différentes fonctions

[guillaume07]

Merci pour ta réponse, cependant un doute subsiste ...

Quel problème peut se poser si mon .exe utilise une version statique de la CRT ou une version1 et qu'une dll utilisé par mon .exe utilise une version dynamique de la CRT ou une version 2 ?

[guillaume07]

http://msdn.microsoft.com/en-us/libr...(v=vs.80).aspx