Discussion :

[vandamme]

Bonjour,

Je me suis toujours demande (dans un contexte monothread) pourquoi, pour écrire un singleton Widget, on ne fait généralement pas :

Code :

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

1
2
3
4
5
6
 
static Widget& instance()
{
  static Widget w;
  return w;
}

ou bien :

Code :

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

1
2
3
4
5
6
 
static Widget& instance()
{
  static Widget* w = new Widget();
  return *w;
}

plutôt qu'utiliser un membre static de la classe Widget :

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
 
class Widget
{
public:
...
 
static Widget& instance()
{
  if (!w)
  {
    w = new Widget;
  }
  return *w;
}
...
 
private:
static Widget* w;
};
 
Widget* Widget::w = 0;

Ce qui est qd même plus long à écrire ...

[farscape]

salut,
dans ton cas tu n'as besoin apparemment que d'une fonction globale ,
mais si ton singleton propose d'autres services comme la libération de la ressource allouée, dans ce cas une classe est plus pratique qu'une fonction globale.
la deuxième forme d'allocation de ta ressource peut être obligatoire si elle a besoin d'un contexte précis pour être instanciée. (dépendance avec une autre ressource de l'application).
donc ça depend de la ressource a partager ,si elle est autonome ou non,
autre point avec des outils comme intellisense (visual c++) je préfère passer par une classe c'est plus pratique a l'utilisation mais plus long a écrire...

[Emmanuel Deloget]

Bonjour,

Je me suis toujours demande (dans un contexte monothread) pourquoi, pour écrire un singleton Widget, on ne fait généralement pas :

Code :

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

1
2
3
4
5
6
 
static Widget& instance()
{
  static Widget w;
  return w;
}

C'est le singleton de Meyer.

ou bien :

Code :

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

1
2
3
4
5
6
 
static Widget& instance()
{
  static Widget* w = new Widget();
  return *w;
}

Ca, c'est une des formes canoniques.

plutôt qu'utiliser un membre static de la classe Widget :

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
 
class Widget
{
public:
...
 
static Widget& instance()
{
  if (!w)
  {
    w = new Widget;
  }
  return *w;
}
...
 
private:
static Widget* w;
};
 
Widget* Widget::w = 0;

Ce qui est qd même plus long à écrire ...

Et ça, c'est le singleton tel qu'il est présenté dans le GoF95 - la forme canonique de base.

Chacune des implémentations a sa spécificité (les deux formes canoniques sont équivalentes, mais le destructeur de Widget n'est pas appelé. Le destructeur du singleton de Meyer est appelé, mais il est difficile voire impossible de savoir quand).

Ensuite, le choix de l'implémentation dépends du projet sur lequel tu travailles. La question de savoir quelle est la forme la plus facile a définir n'a pas véritablement d'intérêt, puisque la bonne réponse à cette question dépends de l'environnement dans lequel le singleton est intégré.

[valefor]

Anecdote :

Avec une vieille implémentation de gcc, sous Solaris, j'ai eu un problème un jour avec ces singletons.

On faisait un chargement dynamique de bibliothèque.
De cette bibliothèque on récupérait un singleton.
On déchargeait la bibliothèque.
On arrêtait le programme et paf segv (que l'on n'a pas vu dessuite, on a cru pendant longtemps que tout fonctionnait bien).

Le problème venait que le destructeur du singleton était appelé après déchargement de la lib.

Avec les versions plus récentes de gcc le problème a été résolu.

[screetch]

en quoi une nouvelle version de gcc resout le probleme ?

[valefor]

Elle résolvait le problème au niveau des atexit ou un truc comme cela... l'ordre dans le quel les fonctions de destruction étaient enregistrées tenait compte du déchargement des bibliothèques :
Avant tout les destructeurs étaient enregistrés à la fin du programme.
Après, je ne sais plus comment cela marchait mais il n'y avait plus le problème.

[Feriaman]

Bonjour,

Je trouve vos réponses (Farscape et Emmanuel Deloget) assez mesurées, il me semble que l'on n'a pas vraiment le choix.

Il me semble que, si l'on veut gérer l'ordre de destruction des singletons, nous sommes "forcés" d'utiliser un

Code :

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

static Widget*

plutôt qu'un

Code :

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

static Widget

,
cf la FAQ ici.

Du coup, ce serait une entorse à la segmentation des responsabilités du code de ne pas gérer la désallocation du pointeur au même endroit que son allocation, c'est à dire dans un objet singleton.

C'est vrai que si on fait différemment, on n'est pas certain que cela se passe mal : il se peut qu'au cours de la durée de vie du projet, personne n'ajoute jamais aucun autre singleton, ou que les nouveaux singletons ne dépendent jamais des anciens pour leurs construction ou leur destruction.

Mais cela me semble être du même ordre que pas mal d'autres risques que l'on ne prend pas : il se peut que si l'on n'initialise pas des variables ou si l'on n'alloue pas de la mémoire avant de s'en servir, on n'obtienne jamais de crash ni de fonctionnement aberrant. Et pourtant on ne fait jamais d'entorse à ces règles, même quand on est sur et certain que cela se passera bien.

Du coup, je me dis qu'il y a quelque chose que j'ai mal compris.
Pourriez-vous m'éclairer ?
Merci par avance

[koala01]

Salut,

C'est tout l'avantage de passer par une classe qui contient un pointeur vers l'élément statique

A partir du moment où ton pointeur est encapsulé, rien ne t'empêche de créer des méthodes qui renverront une référence sur l'instance plutôt qu'un pointeur sur celle-ci...

En effet, tu peux tout aussi bien bien avoir un code proche de

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
class Singleton
{
    public:
        static Singleton& getInstance()
        {
             if(!instance)
                 instance= new Singleton;
             return *instance;
        }
        static void freeInstance()
        {
            delete instance;
            instance = NULL;
        }
    private:
        static Singleton *instance;
};

que de

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
class Singleton
{
    public:
        static Singleton* getInstance()
        {
             if(!instance)
                 instance= new Singleton;
             return instance;
        }
        static void freeInstance()
        {
            delete instance;
            instance = NULL;
        }
    private:
        static Singleton *instance;
};

et, si ton singleton dépend d'un autre singleton, rien ne t'empêcherait même d'écrire un code proche de

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
class Singleton
{
    public:
        static Singleton& getInstance()
        {
             /* Singleton2::getInstance() renvoie également une référence
              * sur l'instance ;)
              */
 
             if(!instance)
                 instance= new Singleton(Singleton2::getInstance());
 
             /* ou, de manière plus lisible: */
             if(!instance)
             {
                 Singleton2 s2=Singleton2::getInstance();
                 instance = new Singelton(s2);
             }
             /* renvoi de la référence sur l'instance */
             return *instance;
        }
        static void freeInstance()
        {
            delete instance;
            instance = NULL;
        }
    private:
        static Singleton *instance;
};

[vandamme]

Et bien merci beaucoup pour vos réponses constructives.

[Emmanuel Deloget]

Pour ma part, et je sais que je vais en surprendre plus d'un, je ne vois pas d'intérêt à vouloir absolument que le singleton soit détruit à un moment quelconque du programme (y compris une fois que main() a fini de s'exécuter). Nous sommes dans un monde simplifié, ou l'OS prends en charge l'unload do process et termine toutes les ressources allouées par ce process. De fait, la mémoire, les fichiers ouverts, etc sont correctement libéré/fermé/etc à la fin du programme.

Certes, on peut toujours me répondre "ça fait un resource leak ! ". Et bien non: puisque le singleton est censé être valide à partir du moment ou il est instancié et jusqu'à la fin du programme (c'est à dire, dans un sens, jusqu'à ce que le dernier destructeur de la dernière instance qui a une durée de vie statique ait fini de s'exécuter), quel leak est-ce que je crée si je ne le libère pas en quittant ? Aucun, puisque sitôt après l'exécution du destructeur du singleton, on est censé redonner la main à l'OS pour qu'il fasse le clean up.

En fait, si on donne à l'utilisateur la possibilité de détruire le singleton quand il le souhaite, on prends le risque de l'autoriser à l'utiliser après qu'il ait été détruit - ce qui est bien plus ennuyeux que de ne pas le détruire au niveau de la maintenance du code.

J'en entends déjà qui me hurlent "mais un utilisateur lambda ne ferais pas ça!". Certes. C'est possible. Le même utilisateur lambda ne déclarera pas deux instances de la même classe si vous lui dites qu'il n'en a pas le droit. Puisque vous vous substituez à son intelligence en interdisant la création d'une seconde instance de votre classe, pourquoi lui permettre de la détruire après ? Ca n'est pas très consistant