Discussion :

[Ruffi]

Salut

Je suis en train de faire une petite dll.
Mais j'ai un probleme lorsque la fonction que j'exporte a un std::string comme parametre (j'imagine que le meme probleme doit se produire pour les autres classes de la STL).
J'avais enlevé le warning 4251 (d'apres des conseils sur un site) qui semble avoir un raport avec mon probleme.

Au chargement de la DLL, si j'ai le malheur d'utiliser la fonction sendMessage( std::string message ), j'ai un beau message box

Le point d'entrée de procedure .sendMessage@cConnection@@QAE_NV?$basic_string@DU?$char_traits@D@std@@V$allocator@D@2@@std@@@Z" est introuvable dans la bibliotheque de liaison dynamique Client DLL.dll.

Comment dois-je faire ?
Dois-je forcement exporter std::string ? (et au passage, comment je le fait ? )

[Médinoc]

Déjà, tu devrais utiliser un "name undecorator" (celui qui est approprié à ton compilo) pour obtenir le prototype exact de cette fonction: Il faut être un expert geek pour reconnaitre soi-même le prototype d'une fonction C++ à partir de son nom...

[Matthieu Brucher]

Non, tu dois exporter ta fonction, là elle n'est pas accessible de l'extérieur.

[Aurelien.Regat-Barrel]

Tu ne peux pas utiliser la STL dans les protoypes de fonctions exportées. Pourquoi ? Parce que ta dll compilée va utiliser sa propre instanciation de std::string, et l'exe qui l'utilise la sienne. Et le compilo ne va y avoir que de feux.
Il faut aussi exporter l'instanciation des conteneurs STL utilisés, ce qui n'est souvent pas possible, et dépendant du compilo.
Pour ce cas très particulier, il faudrait peut être mieux utiliser les char*.
Sinon tu peux plus ou moins ignorer tout ça, mais en fonction des options des compilation, ça peut passer, ou se vautrer.
Cela dit je ne suis pas sûr que ce soit la cause de ton erreur. Sous quel nom est exportée ta fonction ? (regarde avec dependency walker)

[Matthieu Brucher]

Si on compile avec le même compilateur, ça doit passer, non ?

[Ruffi]

J'avoue debuter dans l'univers mysterieux des DLL, je ne comprend trop pas les termes "name undecorator" ainsi que "dependency walker".

"name undecorator", c'est surement pour changer le nom avec lequel il est exporté (le truc super moche avec des @ de partout) par un truc plus lisible. Ca serai effectivement pratique : comment on le met en place (j'utilise visual studio 2003).

Pour repondre à Miles : je pense que la fonction est exporté, dumoins je l'exporte comme les autres fonctions.
L'application compile (donc il retrouve la fonction dans la lib). C'est à l'execution lors du chargment de la dll que j'ai le message box d'erreur.

J'ai pensé utiliser les char*, mais c'est beurk
La FAQ de developpez.com est du meme avis d'ailleur. (et ta signature aussi )

[Aurelien.Regat-Barrel]

Si on compile avec le même compilateur, ça doit passer, non ?

si l'exe et la dll partagent la même crt (désolé Ruffi ), oui. Mais c'est du forcing, car ça n'empêche pas que l'exe et la dll auront chacun leur version de std::string. Mais comme elles seront identiques, ça passe... Pour être fiable, il faut que l'un des 2 (la dll typiquement) exporte sa spécialisation de template que l'autre va utiliser. Mais c'est assez limité ( http://support.microsoft.com/kb/168958/en-us )
http://www.unknownroad.com/rtfm/VisualStudio/warningC4251.html

Par exemple, j'avais une fois installé QT3 en démo pour m'y essayé. QT3 était livré (en démo) compilé avec VC++ 6, et moi je bossais avec VC++ 7.1. Les 2 compilos ont une STL très différente. Du coup, si je passais une std::string de VC++ 7.1 à une fonction QT3 (std::string VC++ 6), boum, plantage. Le compilo lui n'y voyait rien du tout.

J'avoue debuter dans l'univers mysterieux des DLL, je ne comprend trop pas les termes "name undecorator" ainsi que "dependency walker".

"name undecorator", c'est surement pour changer le nom avec lequel il est exporté (le truc super moche avec des @ de partout) par un truc plus lisible. Ca serai effectivement pratique : comment on le met en place (j'utilise visual studio 2003).

dependency walker, c'est simplement un logiciel bien pratique dès qu'on parle de dll:
http://www.dependencywalker.com/

name undecorator, heu, je dirais que c'est un logiciel capable à partir du nom décoré = mangled (le truc super moche avec des @ de partout) de te sortir un com compréhensible. dependency walker sait le faire pour VC++ (petit bouton C++), mais pas pour les autres (car le name mangling est spécifique à chaque compilo )

Pour repondre à Miles : je pense que la fonction est exporté, dumoins je l'exporte comme les autres fonctions.
L'application compile (donc il retrouve la fonction dans la lib). C'est à l'execution lors du chargment de la dll que j'ai le message box d'erreur.

c'est poru ça qu'il faut regarder avec dependency walker ce qu'exporte ta dll. Encore mieux : lance dependency walker sur ton exe, il te dira tout seul ce qui va pas.

J'ai pensé utiliser les char*, mais c'est beurk
La FAQ de developpez.com est du meme avis d'ailleur. (et ta signature aussi )

tu as bien raison, mais là on sort du cadre du C++ (dll), et y'a des contraintes techniques (la STL / les templates se marient mal avec les dll). La solution simple c'est d'utiliser des libs statiques au lieu de dlls.

[Ruffi]

Grace au dependancy walker : bool cConnection::sendMessage(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >)

Pour le coup, je vien de retester mon programme... et ça marche
Alors, pourquoi ça marchait pas hier, mystere et boule de gomme : aurais-je oublié de mettre la derniere version de la DLL (pourtant, je suis persuadé de l'avoir verifié plusieurs fois), ou etait-ce sous l'effet de la fatigue que je commencai a pas trop savoir se que je faisait.

D'apres ce que vous m'avez dit, la DLL ne marchera qu'avec des programmes créé avec un compilateur utilisant la meme version de la STL que visual 2003. Pour tout les autres, il faudra donc la recompiler.

En tout cas, je vous remerci car pour le coup je comprend un peu mieu le fonctionement des dll.