Projet de lib et executable avec code commun

**Ange_blond** · 18/05/2009, 17h25

Hello,

En cette soirée, je me creuse le neurone sur un petit soucis : rien de bien méchant mais juste histoire de me rassurer.

J'ai un big projet, qui compile en exe et en lib. en lib pour que les classes soit dispo pour une autre lib, et en exe... pour le lancer ^^

J'ai donc du déclarer mes classes __declspec(dllexport) pour qu'elles soient accessibles en lib, mais est ce que je dois ne pas les définir ainsi pour l'exe ? ou peu importe ? je peux avec des define ne rien définir en mode exe, mais est-ce utile ? (sécurité, rapidité, ... ?)

Merci.

Ange_blond

**3DArchi** · 18/05/2009, 17h31

J'aurais tendance à dire de ne pas mettre '__declspec(dllexport)' dans l'exe. Après tout, il est toujours inutile d'en faire plus que le minimum requis. C'est souvent source de pb. Je n'ai pas de meilleur justification...

**Ange_blond** · 18/05/2009, 17h50

Je suis un peu du même avis ... sans plus de justification mais par principe de ne pas mettre des trucs inutiles.
J'ai quand meme testé l'exe avec la déclaration, ça ne pose pas de soucis...

**3DArchi** · 18/05/2009, 18h00

Le truc que j'ai jamais essayé c'est de faire un LoadLibrairy sur un exe et voir si les fonctions que tu exportes sont accessibles. Je ne suis pas sûr que ce soit possible mais ça pourrait être problématique.

**Ange_blond** · 19/05/2009, 08h19

Je crois qu'il faut quand meme les définir en extern "C" en plus du dllexport pour pouvoir les récuperer en getProcAdress apres un LoadLibrary.

De toute maniere, je vais faire en sorte que ça ne soit pas défini en exe pi voilà ^^

Merci.

**koala01** · 19/05/2009, 09h35

Salut,

En fait, je dirais qu'il y a deux solutions majeures:

Soit, tu recompile l'ensemble de la bibliothèque lorsque tu compile l'exécutable, et tu n'a pas besoin de lier le projet à la bibliothèque ni du declspec(XXX),

soit, tu utilise la bibliothèque compilée pour compiler le projet.

A ce moment, là, il faut le declspec(dllexport) pour compiler la bibliothèque, le declspec(dllimport) pour compiler le projet et lier dynamiquement le projet à la bibliothèque.

Cela pourrait se traduire par une série d'instructions préprocesseurs proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
#if defined(SHARED)  
    #if defined(BUILD_MYLIB)
        #define MYLIB declspec(dllexport)
    #else
        #defiine MYLIB declspec(dllimport)
    #endif // #defined BUILD_LIB
#else
    #define MYLIB
#endif  //#defined SHARED

**Ange_blond** · 19/05/2009, 10h15

C'est ce que j'ai plus ou moins ... sauf que j'ai jamais compris l'interet du dllimport ...

Ca sert à quoi ? comment et où l'utiliser ?

Merci.

**3DArchi** · 19/05/2009, 10h18

Envoyé par Ange_blond

C'est ce que j'ai plus ou moins ... sauf que j'ai jamais compris l'interet du dllimport ...

C'est juste l'inverse du dllexport... C'est la version qui doit être utilisé par le client de la DLL.
En gros :
dllexport : quand tu génères la DLL. Ca indique au compilo que le symbole doit être exporté.
dllimport : quand tu utilises la DLL (le client). Ca indique au compile que le symbole est import
rien : quand la classe n'est ni exporté ni importé.

**Ange_blond** · 19/05/2009, 10h25

Donc si je comprend bien, les méthodes de ma DLL doivent etre en dllimport ?

en résumé : ma DLL (en dllimport) compile en se basant sur une lib (en dllexport)
pour que tout roule ?

Mais ma dll va ensuite etre chargée par un exe ... donc elle doit etre en dllexport au final non ? ce qui nous donne 2 import/export pour la meme dll...

Merci.

**3DArchi** · 19/05/2009, 10h36

Ben c'est à peu près le sens donné par Koala dans sa définition des directives :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
#if defined(SHARED)  
    #if defined(BUILD_MYLIB)
        #define MYLIB declspec(dllexport) // Pour la génération de la DLL
    #else
        #defiine MYLIB declspec(dllimport) // Pour le client de la DLL
    #endif // #defined BUILD_LIB
#else
    #define MYLIB // Pour générer le code en interne
#endif  //#defined SHARED

Ce qui veut dire :
-> Dans le projet de ta DLL : définir SHARED et BUILD_MYLIB
-> Dans le projet utilisant la DLL : définir seulement SHARED
-> Dans un projet intégrant le code et pas la DLL : ni SHARED, ni BUILD_MYLIB.

**Ange_blond** · 19/05/2009, 10h42

Je vois, mais c'est là que tout se complique :

mon projet EXE, implemente des méthodes que j'exporte pour la dll. (en compilant l'exe en DLL : seules les méthodes déclarées export sont bien dispo, ça marche)
la DLL, une fois operationelle, sera loadé par l'EXE dynamiquement (et pas à la compil)

D'où le fix des flags de compil, car je dois compiler mon exe en dll (avec les dllexport) puis ma dll avec le monexe.lib pour la compilation. Enfin, mon exe va loader ma DLL dynamiquement avec un LoadLibrary.

Donc est ce que j'ai besoin de déclarer le dllimport quelquepart ? et si oui, où ?

Merci.

**3DArchi** · 19/05/2009, 11h43

Dire que je n'ai rien compris serait un doux euphémisme

Tentons une reformulation

1/ Tu as un projet CORE que tu compiles en .lib ;
2/ Tu as un projet DLL qui reprend ce CORE pour des symboles exportés ;
3/ Tu as un projet EXE qui charge dynamiquement la DLL et des symboles.

1/ ?
2/ declspec(dllexport)
3/ Rien puisque tu charge dynamiquement. Tu ne devrais même pas inclure les .h en théorie.

**Ange_blond** · 19/05/2009, 12h06

1, 2 et 3!

a. J'ai un CORE, que je compile en lib. (avec les dllexport sur les classes necessaires)
b. J'ai une DLL, que je compile avec comme dépendance le CORE.lib (donc ma mydll.dll a pour dépendance core.dll)
c. Je reprend mon CORE que je compile en exe, avec pour dépendance dynamique mydll.dll donc comme je charge ma dll dynamiquement, a priori pas besoin de grand chose (ni les .h comme tu l'as dit).

Pour le moment, je sais que c'est un peu tarabiscoté, mais mon CORE.exe au lancement, charge dynamiquement ma dll, qui elle requiere comme dépendance CORE.dll. A priori, ça marche.

La petite particularité est aussi que j'utilise les fonctions statiques dans la dll pour ne pas avoir à utiliser le getProcAdress. (en effet, au chargement dynamique de la dll, la méthode static est instanciée, ce qui par jeu d'heritage et d'include, instancie la classe dans le CORE.exe. Cette classe heritant déjà d'une classe du CORE.dll, j'ai donc acces via les méthodes virtuelles aux méthodes de la classe de la dll.

Je sais que ça parait ingérable, mais je l'ai vu marcher et je tente de reproduire le principe (les avantages de cette méthode sont indiscutables par rapport à un simple getProcAdress)

Est ce que j'ai été plus clair ?

en gros, d'apres moi, je n'ai besoin du dllimport null part, et du dllexport uniquement dans le CORE en mode lib. Non ?

Merci.

**3DArchi** · 19/05/2009, 12h10

Envoyé par Ange_blond

Est ce que j'ai été plus clair ?

Ca m'a l'air sacrément tarabiscoté comme tu dis.

Envoyé par Ange_blond

en gros, d'apres moi, je n'ai besoin du dllimport null part, et du dllexport uniquement dans le CORE en mode lib. Non ?

De ce que j'en comprends :
-> CORE : dllexport
-> MYDLL : dllexport sur ses symboles exportés et dllimport sur les symboles importés de CORE
-> EXE : aucun.

**white_tentacle** · 19/05/2009, 12h10

J'ai toujours pas tout compris.

Mais j'ai l'impression que le code de core.lib va être à la fois dans core.exe et dans mydll.dll (puisqu'elle utilise core.lib).

Je suis même étonné que ça marche

.

**Ange_blond** · 19/05/2009, 12h25

Envoyé par white_tentacle

Mais j'ai l'impression que le code de core.lib va être à la fois dans core.exe et dans mydll.dll (puisqu'elle utilise core.lib).

voui tout à fait.

Le soucis a présent c'est de m'assurer que le bon code est dans le bon fichier... car des sources communes pour une lib et un exe dans ces conditions là c'est pas facile de savoir ce qui est implémenté et où.

-> MYDLL : dllexport sur ses symboles exportés et dllimport sur les symboles importés de CORE

Pourquoi ? la dll est loadé dynamiquement, mais les fonctions ne sont pas chargées en getProcAdress, a priori la dll n'a pas besoin de dllexport.
Ensuite le dllimport je le met où ? dans la dll, sur les trucs que j'importe de la lib ? mais sous quelle forme ? car pr le moment j'ai toujours mis mes dllexport directement au niveau de la classe... comprend pô quelle est leur place exacte aux dllimport ...

**3DArchi** · 19/05/2009, 14h13

Envoyé par Ange_blond

Le soucis a présent c'est de m'assurer que le bon code est dans le bon fichier... car des sources communes pour une lib et un exe dans ces conditions là c'est pas facile de savoir ce qui est implémenté et où.

On comprend que tu te perdes

Envoyé par Ange_blond

Pourquoi ? la dll est loadé dynamiquement, mais les fonctions ne sont pas chargées en getProcAdress, a priori la dll n'a pas besoin de dllexport.

Tu fais un LoadLibrary mais aucun getProcAdress ? A quoi elle te sert ta DLL ?

Envoyé par Ange_blond

Ensuite le dllimport je le met où ? dans la dll, sur les trucs que j'importe de la lib ? mais sous quelle forme ? car pr le moment j'ai toujours mis mes dllexport directement au niveau de la classe... comprend pô quelle est leur place exacte aux dllimport ...

les dllimport servent à dire que les symboles sont importés de la librairies vers le module en cours de compilation.

**Ange_blond** · 19/05/2009, 14h50

Envoyé par 3DArchi

Tu fais un LoadLibrary mais aucun getProcAdress ? A quoi elle te sert ta DLL ?

Parce que je triche en utilisant les propriété des membres static : je déclare un membre static dans le code de la DLL, mais le type de la variable est déclaré dans le CORE, et donc lors du loadLibrary, la variable statique est automatiquement instanciée, et donc le constructeur est appellé depuis le CORE, ce qui me permet, vi heritage et méthodes virtuelles, d'avoir une instance de la classe de ma DLL et ses méthodes associées, tout en étant dans le CORE.

Envoyé par 3DArchi

les dllimport servent à dire que les symboles sont importés de la librairies vers le module en cours de compilation.

Admettons ... je me perd là dedans aussi ...

Visiblement pour le moment, ça a l'air de marcher sans dllimport nul part, donc je vais continuer sagement.

Merci beaucoup.

**white_tentacle** · 19/05/2009, 15h32

Visiblement pour le moment, ça a l'air de marcher sans dllimport nul part, donc je vais continuer sagement.

J'ai quand même envie de dire que tu pourrais aussi mettre core.lib dans un core.dll, qui serait utilisé par core.exe (qui ne contiendrait plus core.lib) et par mydll.dll (qui ne contiendrait pas plus core.lib). Ainsi, tu serais sûr d'avoir la même version de core (parce que le jour où tu essaies d'exécuter un core.exe avec mydll.dll qui contiennent tous deux des versions différentes de core.lib, tu cours à la catastrophe).

En plus, tu gagnerais en occupation mémoire

.

**Ange_blond** · 19/05/2009, 15h53

Pas sûr de comprendre la différence...

* Ma myDll a besoin de CORE.lib pr le linker et CORE.dll pour la runtime.
* CORE.exe a besoin de myDll.dll a un moment donné, mais lors de son chargment cette derniere requiere CORE.dll

C'est complexe, mais je ne vois pas comment je pourrais limiter ce genre de dépendance, et aussi en effet le risque que CORE.dll ne soit pas à jour avec CORE.exe

Projet de lib et executable avec code commun

Bibliothèques C++

Discussions similaires

Partager

Partager