Discussion :

[delire8]

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

[raptor70]

Code :

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

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

[Alp]

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.

[loufoque]

Code :

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

1
2
3
4
5
static CExcel& CExcel::Get()
{
    static CExcel instance;
    return instance;
}

Et écrire

Code :

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

CExcel& obj = CExcel::Get();

Et non

Code :

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

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

ou

Code :

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

CExcel obj = CExcel::Get();

[raptor70]

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

Code :

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

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;
};

[Alp]

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

[raptor70]

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

Oui, mais tout reste sur la stack ...

[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.

[HanLee]

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.

[delire8]

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

Code :

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

1
2
3
 
CExcel*  Obj;
Obj = CExcel::Get()

avec ma classe template :

Code :

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

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 :

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

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

et

Code :

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

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

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


merci

[raptor70]

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 :

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

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();

[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

[raptor70]

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 ...

[Alp]

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.

[Jean-Marc.Bourguet]

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.

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).

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

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 :

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

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.

[Alp]

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

[Jean-Marc.Bourguet]

@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.

[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...

[Jean-Marc.Bourguet]

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.

[screetch]

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.