DLL : création, différentes méthodes ?

Bonjour,

Je dois faire une DLL, j'ai déjà mon code mais je suis un peu perdu pour la créer parce que j'ai vu plusieurs façons de faire et du coup je mélange tout !!

Pour info, ce que je mets dans ma DLL, c'est des classes...
Mais comme j'ai vu, de créer directement un objet dans le programme qui utilise la dll n'est pas recommandé, rien ne m'empêche de créer 2 fonctions pour créer et supprimer un objet de ce type si il faut.

Mais ce n'est pas la le problème, je ne sais pas trop quelle méthode utiliser pour faire ma DLL et donc en fonction de cette méthode, comment elle s'utilise après...

J'ai essayé les 3 différentes façons de créer une DLL sous Visual :
- An empty DLL project
- A simple DLL project
- A DLL that exports some symbols

Il n'y a que le 3ème qui m'a généré un .lib mais je croyais qu'il le fallait ce .lib ?
Il sert quand ? On en n'a pas besoin pour le programme qui va utiliser la DLL ?

Enfin, si quelqu'un peut m'en dire un peu plus..

Merci
Bonne journée

une dll est une librairie. Pour pouvoir l'utiliser dans un autre programme, il faut que les notions que tu y définis (fonction, variables ou autre ) soient visibles de l'extérieur. Voilà pourquoi il te faut choisir le troisième choix qui te propose d'exporter, cad de rendre visible, tes notions.

j'oubliais : le ficlhier .lib permet d'effectuer une édition de lien statique sur ta librairie. Mais tu n'en n'a pas forcément besoin si tu ne charges ta librairie qu'à l'exécution

donc la 3ème méthode, c'est avec les __declspec(ddlexport) etc...
Et donc avec cette méthode, je peux rendre accessible directement une classe ?
Pas besoin de passer par des méthodes pour créer et supprimer les objets de ce type ?

Et dans le programme qui l'utilise, j'ai juste besoin d'inclure le .h ?


Parce que en fait, ce que j'ai testé avec des DLL qu'on utilise déjà pour un programme, c'est que il faut le .lib mais si je crée directement un objet du type qui est dans la classe, après lors du delete, ca crash, voir un autre post ou j'en parle.


Donc, c'est les 2 grosses façons de faire ?
- soit avec l'export et import du coup, et on a juste besoin du .h dans le programme final

- soit avec le .lib mais il nous faut quand même les .h non ?


Dans ces 2 cas, on ne fait pas de chargement dynamique ? avec LoadLibrary... ?

Il te faut de toute façons les header pour que tes déclarations de variables ou de méthodes de ta dll soient reconnues par le compilateur.
Il te faut le .lib si tu veux faire une édition de lien statique.
Et, normalement, tu peux construire un objet d'une classe déclarée dans ta librairie...
Quand tu dis que ça crasche, c'est la compilation ou l'exécution ?

Citation:

---

Envoyé par g0up1l

j'oubliais : le ficlhier .lib permet d'effectuer une édition de lien statique sur ta librairie. Mais tu n'en n'a pas forcément besoin si tu ne charges ta librairie qu'à l'exécution

---

Non non

Quand tu crées une librairie statique ou dynamique (DLL donc) tu as toujours un .lib qui est généré.

Quand tu utilises cette librairie dans un projet statique ou dynamique (DLL donc) ti dois toujours te linker avec le .lib.

En général maintenant, le .lib d'une librairie statique est plus gros que le .lib d'une librairie dynamique.

Pour schématiser, le .lib d'une librairie statique contient du code et des données, le .lib d'une librairie dynamique contient des références à des points d'entrée dans la DLL

Attention, cette explication n'est pas valable si tu charges tes DLL avec LoadLibrary() et utilises les fonctions avec GetProcAddress(), mais c'est une utilisation particulière des DLL

Citation:

---

Envoyé par ram-0000

Non non

Quand tu crées une librairie statique ou dynamique (DLL donc) tu as toujours un .lib qui est généré.

---

oui bien sûr, ce que je voulais dire c'est que si tu charges la DLL avec LoadLibrary, tu n'as pas besoin de linker sur le .lib