Version imprimable
Bonjour,
je travail sous visual studio 2005 et donc sous windows.
Je voudrais savoir si on peut créer une dll contenant une classe avec une lisaison explicite ?
explicite : sans avoir à lier avec un .lib dans l'exécutable, mais grace à LoadLibrary, GetProcAddress, FreeLibrary.
merci !
À moins de n'employer que des fonctions virtuelles, tu ne peux.
Il te faut également exporter une fonction libre qui instancie un objet et retourne un pointeur.
C'est ce que fait COM/OLE avec ces interfaces et la fonction DllGetClassObject() que doit implémenter toute DLL COM/OLE.
oki thx pour ta réponse rapide ;)
bon j'ai réussi à compiler mon projet avec visual studio 2005, mais avec g++ j'ai quelque problème :s
savez vous déjà si cela est possible ? et si oui comment car il n'y a pas beaucoup de documents sur internet pour la compilation d'une dll avec g++...
merci d'avance !
j'ai trouvé une page qui va pouvoir m'aider je pense :)
pour ceux que ça interesse :
http://www.mingw.org/MinGWiki/index.php/sample%20DLL
je teste ça tout de suite !
Bon je vais encore poser une question, et là je seche complet...
(je bosse sous windows)
maintenant je peux soit tout compiler sous Visual Studio 2005, soit tout compiler sous g++
mais si je tente d'utiliser la dll compiler sous visual avec mon exe compilé sous g++, et inversement ça plante méchament...
je pensais qu'une dll compiler sous n'importe quel langage pouvait être utilisé avec n'importe quel langage :?
(je pense peu être savoir d'ou ça vient : les 2 dlls compilées sous g++ et Visual ne fond pas du tout le même poid, donc visual n'externaliserait pas qq truc ?)
merci de tenter de me répondre !
Ca dépend de l'utilisation que tu fais.
Par exemple si tu utilises des classes de la STL dans ce que tu exportes, ça risque de planter car l'implémentation n'est probablement pas la même pour VC++ et MinGW. En gros ta DLL va renvoyer un std::string sous la forme {taille, pointeur}, et, pas de bol, dans ton EXE les std::string sont sous la forme {pointeur, taille}.
Ce n'est qu'un exemple des erreurs qu'on peut avoir en mixant les compilos.
ouai bizarre...
cela concerne juste le C++ ?
car j'ai déjà vu des programmes pouvant utiliser des dlls compilé par n'importe quelle compilateur...
y'aurait pas un truc du genre à ajouter : __stdcall ou __cdecl ?
De plus, les noms de fonctions C++ ne sont pas standardisés sous Windows, seuls les noms C le sont.
C'est pourquoi toutes les fonctions doivent posséder une interface C (c'est pour ça qu'en C++, on les déclare extern "C") pour être utilisées d'un compilateur à l'autre.
Et je plussoie Laurent, il est très déconseillé de passer des types de la STL à travers les frontières d'une DLL.
Tu peux tenter un débogage avec Visual Studio 2005 (exécute ta DLL, et lorsqu'il te demandera quel EXE utiliser, fournis lui celui compilé avec MinGW).
Ca limitera déjà les recherches.
oki, en gros si je veux faire une dll complétement portable par rapport à n'importe quel compilo, faut que je la fasse entièrement en C, prout alors...
Pas entièrement en C, seule l'interface exportée doit l'être.
Et puis là on parlait de fonctions, à mon avis il n'y a aucun problème à exporter des classes.
Si, justement.
L'interface d'une classe est entièrement en C++...
ouai bon j'ai fait quelques tests...
donc les fonctions en C pas de soucis sur leurs exports/imports à partir de n'importe quel exe (g++ ou visual)
par contre les classes ne vont pas du tout... même en utilisant pas du tout la std, ça plante...
j'en conclut donc que pour avoir des dlls utilisable partout il faut qu'elle soit en C et non C++
Oui mais quel genre de problèmes ça peut causer entre compilos différents ? Tu pensais aux décorations de noms ?Citation:
Si, justement.
L'interface d'une classe est entièrement en C++...
C'est ça. Les noms C++ diffèrent d'un compilateur à l'autre (alors que les noms C sont standardisés sous Windows).
Personnellement, je n'est jamais réussi à créer une DLL contenant une classe avec g++
oki, donc pour mes classes en dll ça réduit un peu le champ d'action niveau compilateur :cry:
on va utiliser la bonne vieille méthode C, c'est vraiment dommage, c'est si beau la programmation objet !
re...
je crois avoir trouvé une page internet qui parle de ce problème, mais c'est en anglais et je capte malheureusement pas tout :roll:
http://www.nabble.com/Shareable-bina...-t2334475.html
si quelqu'un comprend !
Les alignements peuvent être différents, le mécanisme des fonctions virtuelles peut être différent, tout comme celui de l'héritage multiple. L'un peut implémenter l'EBCO, pas l'autre,...Citation:
Envoyé par Laurent Gomila
En gros, il faut standardiser l'ABI (application binary interface) pour que ça marche. Il me semble qu'il y avait eu un effort dans ce sens sous Linux, je ne sais pas ce que ça a donné. Sous windows, c'est COM qui sert de standardisation des binaires, avec toutes les lourdeurs introduites par un binding C++ pensé après coup.