Discussion :

[raphchar]

Bonjour

J'amerai savoir comment inclut-on les dll dans un projet en C++.
L'id�e serait d'utiliser aussi des dll en plus-in donc inclure aussi des dll si seulement elles existent. Comment doit-on le sp�cifier dans le code.

J'aurait la m�me question aussi mais dans un projet C++/CLR .

raphchar

[3DArchi]

Bonjour,
Un chargement dynamique de DLL se fait par LoadLibrary/GetProcAdress.

[ram-0000]

Bonjour,
Un chargement dynamique de DLL se fait par LoadLibrary/GetProcAdress.

Sans oublier le FreeLibrary() quand on n'a plus besoin de la DLL

[Ange_blond]

En utilisant les heritages, les variables statiques et le load dynamic, on peut se passer des getProcAdress.

si la DLL impl�mente une classe qui herite d'une classe d�clar�e dans un core, et que :
* dans la dll il y a un membre static
* dans le core il y a la d�claration du membre static avec dans le constructeur une mise en m�moire (pushbask dans une liste ou similaire) de l'element qui vient d'etre construit ...

alors au chargmeent de la DLL, automatiquement ta variable static sera impl�ment�e, le constructeur appell� dans le core, et donc dans le core tu aura ton instance de classe de ta DLL.

Test� et approuv�.
Necessite par contre quelques am�nagements : heritage, m�thodes virtuelles, code dans la DLL et dans le core, DLL qui d�pend donc du core pour compiler et enfin, dans le cs d'un singleton qui est un registre pour gerer les dll dynamiques, il faut que le core soit aussi une lib....

Mais dans certains cas (dans le mien) c'est tres pratique.

[3DArchi]

En utilisant les heritages, les variables statiques et le load dynamic, on peut se passer des getProcAdress.

si la DLL impl�mente une classe qui herite d'une classe d�clar�e dans un core, et que :
* dans la dll il y a un membre static
* dans le core il y a la d�claration du membre static avec dans le constructeur une mise en m�moire (pushbask dans une liste ou similaire) de l'element qui vient d'etre construit ...

alors au chargmeent de la DLL, automatiquement ta variable static sera impl�ment�e, le constructeur appell� dans le core, et donc dans le core tu aura ton instance de classe de ta DLL.

Test� et approuv�.
Necessite par contre quelques am�nagements : heritage, m�thodes virtuelles, code dans la DLL et dans le core, DLL qui d�pend donc du core pour compiler et enfin, dans le cs d'un singleton qui est un registre pour gerer les dll dynamiques, il faut que le core soit aussi une lib....

Mais dans certains cas (dans le mien) c'est tres pratique.

Modulo un bon plat de spaghetti

[Ange_blond]

Oui mais on gagne en utilisation :

les getProdAdress premettent la communication uniquement avec des types du C ... (double d�claration de classe dans le cas o� on veut balader une instance, pas de std::string, ...)
l� on communique direct avec l'instance sans autre restriction.

Chacun choisis le plus adapt� � ses bseoins, dans mon cas c'est tout vu