Détruire un singleton automatiquement ?

Bonjour,

j'ai une classe CSingleton somme toute classique (c'est à dire avec une fonction GetInstance et une autre Kill). Dans mon programme, j'écrit par exemple:

CExcel obj;
Obj = CExcel::Get();


et à la fin, je ne dois surtout pas oublier un petit CExcel::Kill();

Oui mais voilà, je suis tête en l'air... Alors je me demandais s'il n'y a pas moyen, par hasard, de rajouter cela quelque part (dans un destructeur par exemple), de manière à ne plus à me préoccuper de cette ligne. Par exemple, à la fin du programme, l'objet "obj" (CExcel obj) est automatiquement libéré, et ~CExcel() est appelé. J'ai essayé d'ajouter Kill() dedans, mais c'est sans effet.

Bref, comment peut on rendre automatique cet appel ?

Merci

Cordialement

Code:

---

1 2	CExcel obj; Obj = CExcel::Get();

---

A vérifier ... mais je crois que tu fais une copie de ton objet singleton CExcel.. ce qui ne devrait pas arrivé si ton constructeur par copie est privé.

De plus, il n'y a pas de méthode générale pour détruire automatique un singleton seul. Il faut un système a part d'enregistrement de ton singleton et de destruction à la fin de l'application. Mais c'est un système à part du pattern singleton

Là tu cherches quelque chose proche du RAII.
Dans ton programme il n'y a pas une classe qui est instanciée au début et qui est détruite à la fin du programme ? Elle pourrait porter la responsabilité de ton Singleton et le détruire donc à sa propre destruction.

Code:

---

1 2 3 4 5

static CExcel& CExcel::Get() { static CExcel instance; return instance; }

---

Et écrire

Code:

---

CExcel& obj = CExcel::Get();

---

Et non

Code:

---

1 2	CExcel obj; obj = CExcel::Get();

---

ou

Code:

---

CExcel obj = CExcel::Get();

---

Un singleton, normalement, c'est un pointeur static :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

class CExcel { public : static CExcel & Get( void ) { if( instance == NULL ) { instance = new CExcel(); } return *instance; }   static void Kill( void ) { if( instance != NULL ) { delete instance; } }   private : CExcel(){}   static CExcel * instance; };

---

L'implémentation proposée par loufoque est aussi très utilisée raptor ;)

Citation:

---

Envoyé par Alp

L'implémentation proposée par loufoque est aussi très utilisée raptor ;)

---

Oui, mais tout reste sur la stack ...

Et surtout, si t'utilise pas le singleton, on se mange quand même une initialisation, qui peut être couteuse si l'objet est gros.

Citation:

---

Envoyé par Davidbrcz

Et surtout, si t'utilise pas le singleton, on se mange quand même une initialisation, qui peut être couteuse si l'objet est gros.

---

Non, c'est initialisé à la première utilisation de la fonction.

Puis je crois vraiment pas que c'est stocké dans la pile, il faut que je retrouve la référence.
Si c'était stocké sur la pile, alors ce serait dépilé après, et ça serait illogique.

Vous avez raison, j'ai écrit un peu vite. En fait, mon code est le suivant :

Code:

---

1 2 3

CExcel* Obj; Obj = CExcel::Get()

---

avec ma classe template :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

template<class T> class CSingleton { private: static T* m_Instance;   protected: CSingleton(){}; ~CSingleton(){};   public:   static T* Get() { if( !m_Instance ) m_Instance = new T;   return m_Instance; }   static bool Kill() { if( !m_Instance ) return false;   delete m_Instance;   return true; }   };   template <class T> T *CSingleton<T>::m_Instance = NULL;

---

dont dérive CExcel. Puisqu'on en parle, j'ai une petite question : quelle différence y'a-t-il entre écrire :

Code:

---

1 2	CExcel& obj = CExcel::Get()

---

et

Code:

---

1 2	CExcel* obj = CExcel::Get()

---

Ok, l'un est un pointeur et l'autre une adresse, mais en pratique ?


merci

Citation:

---

Envoyé par delire8

Ok, l'un est un pointeur et l'autre une adresse, mais en pratique ?

---

Faux ... l'un est un pointeur (==adresse) et l'autre une référence.

Il est toujours plus intéressant de passer par référence car plutôt que d'accéder à chaque accès à la mémoire, tu travaille directement sur l'objet :

Code:

---

1 2 3 4 5 6 7 8 9 10

CExcel * obj; obj->blabla1(); // 1er accès mémoire obj->blabla2(); // 2e accès a la memoire   // et moins bien que   CExcel & obj; obj.blabla1(); // l'objet est connu ... obj.blabla2();

---

Bien compris ! Le pire étant que je pensais ne faire qu'un seul accès mémoire en passant par les pointeurs... autant dire que ta remarque me fait prendre conscience que j'ai des updates à faire...

merci

cordialement

Citation:

---

Envoyé par delire8

Bien compris ! Le pire étant que je pensais ne faire qu'un seul accès mémoire en passant par les pointeurs... autant dire que ta remarque me fait prendre conscience que j'ai des updates à faire...

merci

cordialement

---

La règle général est de toujours préférer les références aux pointeurs..

EDIT : ... pour les transferts de données ...

La règle c'est de n'utiliser des pointeurs que quand on y est vraiment obligés. Et encore là on peut écrire du code semblable à un code utilisant des références grâce aux smart pointers.

Citation:

---

Envoyé par HanLee

Puis je crois vraiment pas que c'est stocké dans la pile, il faut que je retrouve la référence.

---

Les variables statiques de fonction ne sont pas stockées dans la pile.

Citation:

---

Envoyé par raptor70

Il est toujours plus intéressant de passer par référence car plutôt que d'accéder à chaque accès à la mémoire,

---

Mutatis mutandis, le code généré pour l'utilisation d'une référence a de bonnes chances d'être le même que celui généré pour l'utilisation d'un pointeur (il y a des cas où ce n'est pas le cas, mais je ne vais pas m'étendre dessus ici).

Citation:

---

Envoyé par raptor70

La règle général est de toujours préférer les références aux pointeurs.

---

Citation:

---

Envoyé par Al

La règle c'est de n'utiliser des pointeurs que quand on y est vraiment obligés.

---

Si on exclus les cas où on n'a pas le choix (surcharge d'opérateurs, possibilité d'une valeur NULL), le choix résulte à mon avis plus d'une convention de codage que de règles. Les extrêmes (utiliser toujours des pointeurs ou des références sauf cas où on n'a pas le choix) sont à mon avis mal inspirés. Comme pour le moment l'extrême pro-référence est celui favorisé, je trouve totalement absurde de faire quelque part:

Code:

---

1 2 3

X& x = new X(); ... delete &x;

---

J'ai déjà écrit à ce sujet. Il faudrait que je prenne le temps d'étendre mes explications aux cas autres que le passage de paramètres.

Je pense toutefois qu'il vaut mieux mettre en avant, à l'opposé de beaucoup de cours, les références du C++. Beaucoup de situations obligent des pointeurs, mais on s'en sort désormais très facilement avec, même les "débutants", car de bons outils sont fournis.

@Jean-Marc : une petite Question/Réponse sur le sujet pourrait être très intéressante. Tu sembles avoir de quoi dire sur le sujet ;)

Citation:

---

Envoyé par Alp

@Jean-Marc : une petite Question/Réponse sur le sujet pourrait être très intéressante. Tu sembles avoir de quoi dire sur le sujet ;)

---

J'aime pas les réponses définitives et courtes à ce genre de question.

La question fondamentale est "comment exprimer clairement ses intentions?" et elle est un peu vaste. Elle est compliquée par le fait que les langages de programmation sont généralement des langages répondant à la question "comment?" et non "quoi?" mitigés par quelques provisions permettant des variations (comportement indéfini, règles "as-if", ...).

Une syntaxe donnée devrait avoir une intention et chaque intention sa syntaxe. Dans le cas du C++ et des sémantiques de références, on a deux syntaxes particulières (les pointeurs bruts et les références) et la possibilité de se construire autant de concepts que l'on veut (les pointeurs intelligents). Il faut donc isoler des intentions suffisemment généralistes et les mettre en correspondance avec ce qui est disponible en respectant les contraintes posées par le langage.

Pour le sens que je donne aux références du C++, c'est d'être un alias localisé, on arrive donc à mes règles opératives (et admettant des exceptions) sont
- ne jamais devoir utiliser l'opérateur &;
- toujours pouvoir passer une variable locale quand on demande une référence
Je remarque aussi qu'en pratique je n'utilise jamais de référence pour des objets qui ne sont pas instantiables sur la pile.

Ma solution est la meilleure, c'est tout, y'a pas à chercher plus loin.
D'après GCC et C++0x, elle est aussi thread-safe...

Citation:

---

Envoyé par loufoque

Ma solution est la meilleure, c'est tout

---

Bof..., elle ne permet pas de gérer le cas où le type le plus dérivé du singleton est déterminé dynamiquement et il n'y a pas moyen de contrôler l'ordre de destruction.

Citation:

---

Envoyé par loufoque

Ma solution est la meilleure, c'est tout, y'a pas à chercher plus loin.
D'après GCC et C++0x, elle est aussi thread-safe...

---

elle SERA, alors. car sur les compilos actuels a la norme actuelle, tu l'as dans l'os.

Ça l'est déjà dans GCC depuis bien longtemps...

ce n'est pas la definition d'un standard ni de code portable.

Oui mais je pense que loufoque voulait dire que comme c'est déjà sur GCC, ça a de fortes chances d'être suivi par les autres gros compilos, petit à petit.

Il y a de toute manière pleins de problêmes à ce code... Même si c'est celui que j'utilise dans pas mal de cas.

Le principal étant qu'il n'empêche pas une mauvaise programmation. Si le constructeur de l'objet statique entraine l'appel à la fonction, thread-safe ou pas... ca va foirer.


Et puis, vraiment (à part peut être pour gcc) il n'est PAS thread-safe (rien ne force un compilo à le rendre thread-safe). Et je n'ai pas vu de futur standard indiquant qu'il le devienne.

Le code généré par le compilo est ni plus ni moins que:

Code:

---

1 2 3 4 5 6 7

if (!is_set) { is_set = true; new(&t)(...); deleteatexit(&t); } return &t;

---

A noter qu'il serait très facile pour le compilo de remplacer le 'is_set' par un truc genre:

Code:

---

1 2 3 4 5 6

if (!(InterlockedOr(&bitfield,0x0000001) & 0x0000001) { new(&t)(...); deleteatexit(&t); } return &t;

---

Mais là encore, ce n'est pas thread-safe... Le return &t; pouvant avoir lieu dans un thread qui croit que l'objet est construit alors qu'il est en train d'être construit.

La solution a base de Critical Section est loin d'être simple ! (http://www.codeguru.com/cpp/misc/mis...le.php/c12897/)
L'overhead par rapport au code initial est tellement rédibitoire que ce *doit* être une option de compilation dans tous les cas.

Pour finir, et contrairement à ce que j'ai vu passer, l'ordre de destruction est parfaitement défini: c'est l'ordre inverse de construction... Et lui pour le coup, est parfaitement thread-safe ! :D

c'est pas une solution a base de section critique, c'est une solution pour initialiser une section critique.
Il y a la possibilité du double locking si on initialise un pinteur

Code:

---

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

A* get() { static A* obj; if(!obj) { DWORD init = 0; if(InterlockedCompareExchange(&init, 1, 0) == 0) //si on aquiere le lock { obj = new A; } while(!obj); // sinon, attente active que le pointeur soit différent de 0 } return obj; }

---

Voir dans le prochain standard pour savoir ce que doit faire un compilo pour rendre ces choses-là thread-safe.
L'implémentation de GCC n'est pas conforme car elle peut deadlocker dans certains cas.

Citation:

---

Envoyé par screetch

c'est pas une solution a base de section critique, c'est une solution pour initialiser une section critique.

---

Heu.... t'as pas du tout lire alors...
Le dernier code montre un exemple pour *rajouter* une partie synchronisée sur l'objet. Si tu remontes au code d'avant tu comprendras...

Citation:

---

Il y a la possibilité du double locking si on initialise un pinteur

---

Heu... on parlait d'une solution à base de :

Code:

---

static A obj;

---

pas de singleton à base de pointeur à coder soi meme !!!

D'ailleurs, dans ton code, il manque un atexit sur une fonction qui va faire le "delete obj" aussi... du coup, le static obj doit être sorti de la fonction pour un résultat *très* loin de la solution initiale:

Code:

---

1 2 3 4 5

{ static A obj; return &obj; }

---

:)

oué oué. ou en etant constructif, mon code + ton code = ca marche.

Je me demandais s'il ne fallait pas redéfinir le constructeur par copie et l'opérateur '=' afin d'éviter de créer plusieurs instances. Peut-être quelque chose m'échappe ?