Discussion :

[babar63]

Bonjour a tous,
Je suis actuellement en train de develloper une dll pour la premiere fois. Enfin fini et apres avoir corriger quelques erreurs j'obtiens bien ma dll et ma librairie statique. Le probleme c'est qu'en la testant, la dll fonctionne seulement lorsque je suis en mode release (pour la dll crée en release) et en mode debug (pour la dll crée en mode debug). Il semblerait que dans les deux cas le probleme viennent de la perte de l'adresse des paramètres envoyés dans une fonction membre . La dll a été créée a l'aide de Visual 2005 (projet Win32 dll). J'ai cherché dans la faq ainsi que deux autres articles appartenant a developpez mais je ne crois pas avoir trouvé de reponse!
Si cela peut vous aider voila comment j'ai defini ma configuration dans le projet :

Code :

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

1
2
3
4
5
6
7
//config.h
...
#ifdef _WINDLL
#define IMPORT_EXPORT __declspec(dllexport)
#else
#define IMPORT_EXPORT __declspec(dllimport)
#endif

Et dans la declaration de mes classes :

Code :

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

1
2
3
4
5
6
//class.h
#include <config.h>
...
class IMPORT_EXPORT MaClass{
...
};

J'avoue que j'ai un peu survolé l'étape de l'apprentissage pour créer une dll pour mieux me concentré sur le code ! Auriez-vous une idée d'ou se situe le probleme?
Merci d'avance, bonne journée

[koala01]

Salut,

J'aurais presque envie de dire que c'est normal.

En effet, il y a souvent une option de compilation (-DDEBUG, par exemple) rajoutee pour indiquer que la dll est compilee en mode debug, ce qui a pour effet d'y inclure une serie de choses, allant des assertions jusqu'a certains symboles, necessaires... au debuggage.

Tu devrais donc pouvoir utiliser la dll "debug" pour une application en mode release, mais, par contre, il est peu vraissemblable que l'utilisation de la dll release fonctionne avec une application en mode debug.

L'idéal est donc, sans doute, de fournir un nom legerement different pour la dll en mode debug, de manière à pouvoir faire le distingo, et permettre à l'utilisateur de choisir celle qu'il veut utiliser

Une convention que l'on rencontre souvent est, tout simplement, de rajouter la lettre d en fin de nom (madll.dll d'un cote, madlld.dll de l'autre),

[Jean-Marc.Bourguet]

Je ne connais pas Windows et ne peux donc pas commenter sur la nature et les causes du probleme. J'ai par contre beaucoup de mal a considerer comme normal de ne pas pouvoir utiliser une bibliotheque "release", qu'elle soit dynamique ou non, dans un build debug. (L'inverse, ne pas pouvoir utiliser la bibliotheque debug dans le build release, me semble plus comprehensible mais neanmoins pas particulierement acceptable et encore moins desirable).

[Médinoc]

Note: au passage sur la façon dont est faite ta DLL: À moins que ta DLL s'appelle "IMPORT.DLL", je te déconseille d'appeler ton define "IMPORT_EXPORT". Tu devrais lui donner un nom unique, typiquement NOMDELADLL_API.

[babar63]

Merci pour vos reponse, si je n'ai pas le choix alors je vais faire comme ca, c'est en effet la méthode que j'employait pour créer des librairies statiques. Mais quelques choses me chagrine quand meme. Pourquoi certaines dll (et meme lib) fonctionnent très bien dans les deux cas de figures, il doit bien exister une solution non? par exemple la librairie glut32.dll ou SDL.dll peuvent etre utilisées en mode debug et release...

[Médinoc]

Je dirais que ça doit surtout dépendre de la façon dont la DLL en question utilise la C Run-Time Library (CRT). Car si tu mélanges Debug et Release, tu auras deux versions de la CRT chargées dans le même processus...

[koala01]

C'est vrai que le terme "normal" est particulièrement inadapté...

j'aurais du utiliser le terme "compréhensible" (et encore )

Toujours est-il que cela peut, entre autre, venir de la manière dont ta bibliothèque est liée avec celle dont elle dépend en mode release et en mode debug...

S'il se fait, d'une manière ou d'une autre, qu'une distinction est effectuée dans le choix des bibliothèques dépendantes selon le mode de compilation choisi, tu te trouvera vraisemblablement confronté à cette nécessité de devoir créer une dll "release" et une "debug" (l'inverse étant tout aussi envisageable, bien sur )

[babar63]

Donc si j'ai bien compris ce serait mon cas étant donné que j'utilise justement un code different en fonction de la macro "_DEBUG" ? Le mystere est-il résolu ou alors j'ai rien compris...

[koala01]

A vrai dire, tout dépend de ce qui sera déclaré en mode "debug" et de ce qui le sera en mode "release"...

Si, pour une raison qui ne tient qu'à toi, tu as une fonction qui n'est déclarée que sur un #ifdef DEBUG ou similaire, appelée depuis l'application, mais qui n'existe purement et simplement pas en mode release, tu tiens effectivement la raison qui fait que... et donc la résolution du mystère.

Si, par contre, la gestion "debug" vs "release" se fait tout à fait en interne (à la dll), il n'y a normalement aucune raison pour ne pas pouvoir utiliser la version "debug" dans une application en "release" ou l'inverse.

Dans ce cas, la seule différence notable serait que:

• dans le premier cas, tu dispose au sein de la dll d'informations de debuggage inutilisées (avec tout ce que cela implique en terme de taille et de performance de la dll)
• dans le deuxieme, que tu ne puisse pas utiliser les informations de débuggage de la dll

[babar63]

Oui c'est bien mon cas, j'ai en effet une fonction déclarée seulement en mode Debug donc je suppose que le probleme vient de la... Merci beaucoup pour m'avoir éclairé Le probleme est donc résolu.

[Invité]

J'ajoute aux conseils de mes illustres pairs que l'un des très gros points noirs lorsqu'on croise une appli Debug avec une DLL non-debug (et vice versa), c'est l'allocateur de mémoire. Ils sont tout simplement différents en debug et release, et l'un ne peut pas travailler avec les blocs mémoire de l'autre.

Regarde comment fonctionnent les DLL de Windows, User32.dll, Gdi32.dll et Kernel32.dll, qui sont liées à presque toutes les applis, debug comme release. L'astuce, c'est que tout objet alloué dans le code de ces DLL y est également désalloué. C'est pour cela que tu reçois des HWND et des HPEN et des HANDLE à tout va plutôt que des pointeurs que tu peux free()-er ou delete-er. Chaque handle que tu reçois d'une DLL doit lui être rendu. Ainsi, c'est le même allocateur qui s'en occupe.

Si maintenant du as une DLL avec une fonction qui crée et renvoie un objet, et que tu delete cet objet dans ton appli, si les allocateurs sont différents, Toto va désallouer un objet géré par Gus, et c'est la fin des haricots.

Carl

[babar63]

Merci pour ton conseil Carl, en fait c'est un peu particulier puisque je construit un manager de memoire en suivant le fameux tutoriel de laurent gomila sur la conception d'un moteur3D donc je desalloue seulement si Gus a oublier de le faire et seulement en mode Debug... J'ai bien créé deux librairies statiques et dynamiques différentes donc je ne devrait plus avoir de problème. Encore merci à vous pour m'avoir éclairé.

[babar63]

Petite mis à jour en espérant que cela pourrait pourra aider à d'autres... J'ai eu l'occasion d'approfondir un peu plus la question et au final j'étais à coté de la plaque...
La gestion des pointeurs était à priori très bien séparés entre mon application et ma dll... mais seulement a priori! En fait le problème venait des fonctions inlines qui allouaient des pointeurs gérés par ma dll... c'est tout bête mais il fallait y penser
Encore merci pour m'avoir aidé à comprendre comment tout cela fonctionnait