Discussion :

[moooona]

Bonjour,
J'ai créé une DLL (win32) (test.dll).
Je veux maintenant l'utiliser dans un autre projet (projet 2).
Donc j'ai pris le fichier .lib et je l'ai mis avec le code du projet 2.
Ensuite, j'ai mis le .dll dans le répertoire debug.
Propriétés du projet>Editeur des liens>Entrée>dépendances supplimentaire> test.lib.

Dans cette DLL, j'ai un fichier client.h.
lorsque j'ai mis #include "client.h": dans projet 2, il m'affiche: impossible de trouver les fichiers.
Je veux pas ajouter les fichiers de la dll dans projet 2. J'utilise VC++ 2008
est ce que quelqu'un peut m'aider.
merci

[jblecanard]

Salut moooona

Alors déjà, une petite précision : si tu utilises la DLL, tu n'as à priori pas besoin du *.lib, et inversement. Les *.lib servent pour une édition de liens statique, et les *.dll pour une édition de lien dynamique. Il te faudra faire un choix.

Sinon pour ton problème, c'est parce que tu confond les headers et la dll.

Dans cette DLL, j'ai un fichier client.h.

Une DLL ne contient pas de fichiers. Pour utiliser une DLL dans un autre programme, il faut que celui-ci ai aussi accès aux headers que tu veux lui permettre d'utiliser. Donc il faut ajouter le répertoire qui contient client.h dans les includes de ton projet.

Tu vas Propriétés du projet> C/C++ > Général > Répertoires d'include additionnels (mon visual est en anglais, j'ai vaguement traduit). Et tu ajoutes le ou les répertoires nécessaires, séparés par des points virgules.

[moooona]

oui c'est vrai. Il me faut ajouter le répertoire qui contient les fichiers de la dll

Propriétés du projet> C/C++ > Général > Répertoires d'include additionnels

Mais ce que je veux exactement est d'utiliser les méthodes de la dll sans donner le répertoir du client.h.
En fait, j'ai une dll qui contient un ensemble des classes et des méthodes.
Je veux utiliser la dll sans code source.
c'est à dire, en supposant que je sais les méthodes que je vais l'utiliser dans projet2 et j'ai pas le code source de la DLL.
Comment je peux faire pour que je puisse utiliser les méthodes de la DLL dans projet 2.

[Charlemagne]

Alors déjà, une petite précision : si tu utilises la DLL, tu n'as à priori pas besoin du *.lib, et inversement. Les *.lib servent pour une édition de liens statique, et les *.dll pour une édition de lien dynamique. Il te faudra faire un choix.

Faux en fait.
Visual génére avec la DLL également la LIB correspondante. C'est un fichier de toute petite taille qui fait appel à la DLL. Ca permet de linker de la mème manière qu'avec une librairie statique.
C'est très pratique, car il n'est en pratique que rarement utile de gérer le chargement de la DLL soi-même (LoadLibraryA, FreeLibrary, GetProcAddress...)

[Emmanuel Deloget]

oui c'est vrai. Il me faut ajouter le répertoire qui contient les fichiers de la dll

Mais ce que je veux exactement est d'utiliser les méthodes de la dll sans donner le répertoir du client.h.
En fait, j'ai une dll qui contient un ensemble des classes et des méthodes.
Je veux utiliser la dll sans code source.
c'est à dire, en supposant que je sais les méthodes que je vais l'utiliser dans projet2 et j'ai pas le code source de la DLL.
Comment je peux faire pour que je puisse utiliser les méthodes de la DLL dans projet 2.

C'est pas possible. Comment est-ce que le compilateur va faire pour déviner le nom des fonctions, le nombre de paramètres, etc ? Il lui faut ces informations, et elles ne sont pas dans la DLL (ou dans le .so sur les autres plateformes).

Lorsque tu fournis un SDK, tu fournis une DLL, ds fichiers headers et généralement une librairie statique permettant à celui qui le souhaite de faire le lien direct avec la DLL (c'est une librairie d'import). C'est comme ça

[jblecanard]

c'est à dire, en supposant que je sais les méthodes que je vais l'utiliser dans projet2 et j'ai pas le code source de la DLL.
Comment je peux faire pour que je puisse utiliser les méthodes de la DLL dans projet 2.

Tu peux cacher l'implémentation (le contenu des *.cpp) mais tu ne peux PAS cacher les interfaces dont tu as besoin (le contenu des *.h). C'est une des raisons pour lesquelles on utilise justement deux fichiers, un pour l'interface, un pour l'implémentation.

[Jean-Marc.Bourguet]

Bonjour,
J'ai créé une DLL (win32) (test.dll).
Je veux maintenant l'utiliser dans un autre projet (projet 2).
Donc j'ai pris le fichier .lib et je l'ai mis avec le code du projet 2.
Ensuite, j'ai mis le .dll dans le répertoire debug.
Propriétés du projet>Editeur des liens>Entrée>dépendances supplimentaire> test.lib.

Dans cette DLL, j'ai un fichier client.h.
lorsque j'ai mis #include "client.h": dans projet 2, il m'affiche: impossible de trouver les fichiers.
Je veux pas ajouter les fichiers de la dll dans projet 2. J'utilise VC++ 2008
est ce que quelqu'un peut m'aider.
merci

Est-ce que modifier la liste des repertoires cherches pour les fichiers inclus est une solution acceptable? Sinon donne plus de renseignement sur ce que tu veux accomplir et pourquoi.

Les bibliotheques dynamiques permettent de retarder le moment ou l'edition de liens est faite. Plutot que lorsque le programme est batit, ca peut se faire au lancement du programme ou meme pendant son execution. Pourquoi est-ce qu'on veut faire ca?

Historiquement, une raison principale etait pour economiser la place sur le disque en evitant que les differents programmes aient chacun leur copie. Cette raison n'a generalement plus lieu d'etre de nos jours.

Une autre raison est de pouvoir mettre a jour la bibliotheque sans changer le programme. C'est une raison toujours valable, mais ca demande une excellente maitrise de ce qu'il est possible de changer et de ce qu'il n'est pas possible de changer.

Dans ces deux cas, on retarde l'edition de liens au lancement du programme. Ca se fait sous Windows en liant avec un .LIB special, sous Unix en liant avec le .so. Dans ce genre de contexte, le programme utilisant la bibliotheque dynamique est concu et ecrit comme si c'etait une bibliotheque statique: seul l'edition de liens change. Il est donc de bonne pratique de referencer les entetes definissant l'interface de la bibliotheque (generalement il seront trouves parce qu'on aura specifie au systeme de build un repertoires ou chercher pour trouves les fichiers inclus).


Dans quels cas peut-on vouloir retarder encore plus le chargement? Deux grandes classes:
- la bibliotheque est connue quand on batit le programme; mais on ne veut pas la charger directement pour differentes raisons (par exemple economiser la memoire, diminuer le temps de chargement, en particulier si la bibliotheque n'est pas toujours utilisee).
- la bibliotheque n'existe pas encore, ou du moins est concue de maniere separee. Exemple typique: les plugins.

Dans la premiere cas, on peut agir comme avec une bibliotheque statique (et donc avoir besoin des entetes), specifier a l'edition de liens qu'on accepte d'avoir des symboles non resolus et charger explicitement la bibliotheque avant d'appeler les fonctions. (Je ne sais pas si c'est techniquement possible sous Windows). On peut aussi considerer la bibliotheque comme un plugin.

Dans le cas des plugins, ce n'est plus le programme qui doit utiliser la bibliotheque en respectant son interface, c'est la bibliotheque qui doit fournir l'interface attendue par le programme. Et la maniere la plus simple de le faire est que le code de la bibliotheque inclu des entetes fournit par le programme et definissant l'interface. D'autes techniques sont possibles, ecrire le code sans essayer d'utiliser le langage pour verifier la coherence -- mais pourquoi diable chercher des problemes? -- ou accompagner la bibliotheque d'un fichier decrivant l'interface fournie ou meme ecrire le code sans verifier les attentes (mais le programme principal doit savoir lire ce fichier et en faire quelque chose, c'est peut-etre le plus souple au final, mais c'est le plus complexe a mettre en oeuvre).

tl;dr Le programme et la bibliotheque doivent etre d'accord sur l'interface. La maniere la plus simple d'y arriver est que l'un des deux inclus des entetes fournis par l'autre.

[ram-0000]

Dans quels cas peut-on vouloir retarder encore plus le chargement? Deux grandes classes:
- la bibliotheque est connue quand on batit le programme; mais on ne veut pas la charger directement pour differentes raisons (par exemple economiser la memoire, diminuer le temps de chargement, en particulier si la bibliotheque n'est pas toujours utilisee).
- la bibliotheque n'existe pas encore, ou du moins est concue de maniere separee. Exemple typique: les plugins.

J'en rajouterai une 3eme, la portabilité. Lorsque l'on veut utiliser une API plutôt qu'une autre en fonction de la version du systeme d'exploitation. Exemple récent (et vécu), Sur Windows pre-Vista, utiliser l'ancienne "API EventLog", sur les versions Vista et supérieures, utiliser la nouvelle "API Event Logging". Dans ce cas, tout se passe avec des LoadLibrary, GetProcAddress et autre pointeurs de fonction puisque les DLL de la nouvelle API n'existent pas sur les anciennes versions.