pointeur extern et DLL

Bonjour,
j'ai un soucis et je crois savoir d'où il vient. Je voudrais confirmation.

J'ai, dans une DLL :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

class Base;   class Derivee : public Base { };   Derivee * uniqueInstance = NULL;   Base * createInstance() { uniqueInstance = new Derivee(); return uniqueInstance; }

---

Puis une application qui appelle createInstance() et qui interagit avec l'interface Base.

Pour plus de comodité, j'avais écrit dans cette DLL partout où j'avais besoin de mon instance :

Code:

---

extern Derivee * uniqueInstance;

---

Et je m'en servais pour interroger des propriétés de l'instance.

Seulement voila, l'application peut charger plusieurs fois ma DLL et j'ai l'impression que les pointeurs extern des deux DLL pointent vers le même objet. Alors que deux new ont été appellés.

Donc ma question : un pointeur extern dans une DLL est-il partagé pour toute les DLL de l'appli ?

l'utilisation d'extern n'est pas la bonne approche.
extern sert a dire au compilo "ceci est definit dans un autre module"
dans ton cas declare plutot uniqueInstance en static (comme tout singleton)
et utilise __declspec( dllexport ) pour partager ton singleton avec ton client.

fichier .h

Code:

---

1 2 3 4 5 6 7 8 9

class __declspec( dllexport ) Derivee : public Base { public: static Base* createInstance(); private: static Derivee * uniqueInstance; };   Derivee * Derivee::uniqueInstance = NULL;

---

.cpp

Code:

---

1 2 3 4 5 6

Base * Derivee::createInstance() { uniqueInstance = new Derivee(); return uniqueInstance; }

---

Oui je peux utiliser un singleton, mais j'avais pensé à extern pour ne pas avoir à sortir l'artillerie lourde. (je sais que mon pointeur est toujours non null et aucune chance qu'il puisse avoir une autre instance.)
Mais la solution est, comme tu le dis, de placer le pointeur en static dans la classe, quitte à le mettre public après.

Citation:

---

extern sert a dire au compilo "ceci est definit dans un autre module"

---

Ben c'etait un peu ça l'idée. De dire que le pointeur se trouve dans une autre unité de compil (autre cpp). Mais visiblement si je charge deux fois ma DLL ça ne marche plus.

Citation:

---

Envoyé par NiamorH

Seulement voila, l'application peut charger plusieurs fois ma DLL ...

---

Comment c'est possible de charger 2 fois (ou plus) la même DLL ? Ou alors elle est déchargée entre temps ?

en effet une dll ne marche pas comme une instance en memoire

Alors ce qui doit se passer (je n'ai pas du tout accès au code et je ne m'y connais pas trop en DLL) c'est que l'appli charge une seule fois la DLL mais appelle deux fois la méthode GetInstance(). Dans ce cas là je suis dans la m.... car même un singleton ne fonctionnera pas.

Je vais devoir passer un pointeur vers mon objet dans les contructeurs des classes qui en ont besoin... faich :lol:

Citation:

---

Envoyé par 5:35pm

l'utilisation d'extern n'est pas la bonne approche.
extern sert a dire au compilo "ceci est definit dans un autre module"
dans ton cas declare plutot uniqueInstance en static (comme tout singleton)
et utilise __declspec( dllexport ) pour partager ton singleton avec ton client.

fichier .h

Code:

---

1 2 3 4 5 6 7 8 9

class __declspec( dllexport ) Derivee : public Base { public: static Base* createInstance(); private: static Derivee * uniqueInstance; };   Derivee * Derivee::uniqueInstance = NULL;

---

.cpp

Code:

---

1 2 3 4 5

Base * Derivee::createInstance() { uniqueInstance = new Derivee(); return uniqueInstance; }

---

---

Très bonne idée que de faire une dll en bonne et due forme mais à quoi cela sert il si l'on ne corrige pas, par la même occasion, les fuites de mémoires qu'engendre plusieurs appels à createInstance() ?

Code:

---

1 2 3 4 5 6 7 8 9

Base * Derivee::createInstance() { if(!uniqueInstance) { uniqueInstance = new Derivee(); } return (Base*) uniqueInstance; }

---

sans oublier la destruction de l'instance :

Code:

---

1 2 3 4 5 6 7 8 9

void Derivee::destroyInstance() { if(uniqueInstance) { delete uniqueInstance; } uniqueInstance = NULL; }

---

Citation:

---

Envoyé par NiamorH

Oui je peux utiliser un singleton, mais j'avais pensé à extern pour ne pas avoir à sortir l'artillerie lourde. (je sais que mon pointeur est toujours non null et aucune chance qu'il puisse avoir une autre instance.)
Mais la solution est, comme tu le dis, de placer le pointeur en static dans la classe, quitte à le mettre public après.



Ben c'etait un peu ça l'idée. De dire que le pointeur se trouve dans une autre unité de compil (autre cpp). Mais visiblement si je charge deux fois ma DLL ça ne marche plus.

---

Si ! Il y a plusieurs instances de Derivee(1 par appels à createInstance) mais seulement 1 seul pointeur ! Le fait qu'il soit non null ne change rien au problème. Tu à des fuites de mémoires !

Les unités de compils ne sont pas des .cpp mais des .o et si tu a le cpp d'origine fais les modifs que l'on t'a prescrites et vois si tu peux pas directement inclure le cpp a ton projet.

Citation:

---

Envoyé par doccpu

ou tu demande a celui qui a fait la dll de faire son job correctement !

---

He, doucement.
Ne dis pas ça, j'ai fait cette DLL dans le cadre de mes loisirs et il se trouve que c'est la premiere fois que je suis amené à en faire une moi même.

L'application mère est un logiciel commercial qui dispose d'un sdk minimum pour fournir des DLL.

Dans ce sdk, il y a en gros une interface nommée Base on va dire et une méthode (non membre) createInstance() qui renvoie un pointeur vers une Base.

Jusque la pas de soucis.

Maintenant j'écarte totalement l'idée d'une instance unique type singleton ou même pointeur extern car je viens de comprendre le fonctionnement réel.

J'étais parti dans l'idée que la dll se chargeait n fois, tout comme on pourrait lancer plusieurs instances d'un même exe.

Je vois mon erreur, je corrige, point...

Citation:

---

Envoyé par doccpu

Très bonne idée que de faire une dll en bonne et due forme mais à quoi cela sert il si l'on ne corrige pas, par la même occasion, les fuites de mémoires qu'engendre plusieurs appels à createInstance() ?

---

oui bon ca va tout le monde sait a quoi ressemble un singleton =)
ceci dit, cette implementation n'est pas thread safe :P

effectivement on a pas mis de sémaphores !