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