Discussion :

[djuju]

Bonjour,

Dans une application multi-thread, j'utilise un singleton basé sur un shared_ptr

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
36
37
 
	namespace usb {
 
		class cUSBManager
		{
		  /* ATTRIBUTES */
		  static boost::shared_ptr<cUSBManager> saSINGLETON_INSTANCE;
 
		protected:
		  (... des champs ...)
 
		  /* METHODS */
		public:
		  ~cUSBManager();
 
		  (... des méthodes ...)
 
		  static boost::shared_ptr<cUSBManager> mGetInstance();
 
		private:
		  // This class is a singleton, use factory to get the instance
		  cUSBManager();
		};
	}
 
 
/* Statics var and func for singleton management */
boost::shared_ptr<cUSBManager> usb::cUSBManager::saSINGLETON_INSTANCE = boost::shared_ptr<cUSBManager>();
 
boost::shared_ptr<cUSBManager> usb::cUSBManager::smGetInstance()
{
  if(!cUSBManager::saSINGLETON_INSTANCE.get())
    cUSBManager::saSINGLETON_INSTANCE = 
      boost::shared_ptr<cUSBManager>(new cUSBManager());
 
  return cUSBManager::saSINGLETON_INSTANCE;
}

Lorsque j'ai testé ce code pour la première fois Visual Studio m'a rapporté une fuite de mémoire. Cependant, il semble s'agir d'un faux positif dû au fait que la détection des fuites de mem. est faite avant la destruction des champs statiques. Je suis d'ailleurs capable de m'arrêter sur un break point dans le destructeur de saSINGLETON_INSTANCE.
Ce problème est pénible car je ne voudrais pas devoir trier tous les rapports de fuite de mémoire.

D'où ma question: comment peut on se débarrasser mon output de ces fausses (si elles le sont vraiment) fuites de mémoires ?

Merci d'avance
Ju

[poukill]

Je ne comprends pas pourquoi tu utilises un shared_ptr ici. C'est un singleton, il n'y a pas de responsabilité partagée.
Pourquoi ne pas renvoyer une référence ?

[djuju]

Je ne comprends pas pourquoi tu utilises un shared_ptr ici. C'est un singleton, il n'y a pas de responsabilité partagée.
Pourquoi ne pas renvoyer une référence ?

Oui oui, tu as entièrement raison.
On devrait plutôt avoir un truc du genre :

Code :

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

1
2
3
4
5
6
7
8
9
 
cUSBManager* usb::cUSBManager::smGetInstance()
{
  if(!cUSBManager::saSINGLETON_INSTANCE.get())
    cUSBManager::saSINGLETON_INSTANCE = 
      boost::shared_ptr<cUSBManager>(new cUSBManager());
 
  return cUSBManager::saSINGLETON_INSTANCE.get();
}

Mais je veux garder mon instance dans un shared_ptr pour ne pas avoir à faire un appel explicite au destructeur
Je voudrais aussi que mon singleton crée son instance au premier appel à smGetInstance(), et la garde jusqu'à la fin de l'exécution du code.

Ju

[nikko34]

Tu en as vraiment besoin ou ça ne te dérange pas d'initialiser le singleton avant le lancement de tes threads? C'est le plus simple.

[djuju]

Tu en as vraiment besoin ou ça ne te dérange pas d'initialiser le singleton avant le lancement de tes threads? C'est le plus simple.

Merci de ton aide...

En fait, pour une execution donnée, je ne suis pas sur que le singleton sera demandé. Si il est demandé, il le sera un grand nombre de fois.
La création de mon singleton est couteuse car il initialise récursivement un modèle mémoire de l'arbre des périfériques USB de ma machine. Je voudrais évité ça si ce n'est pas utile.
Mais au final, après vos commentaires, je me demande si le plus simple ne serait pas de créer mon singleton à l'initialisation du code (sans le conserver dans un shared_ptr), mais de faire l'initialisation uniquement lors du premier appel à smGetInstance().
Je perd un peu de mémoire si mon singleton n'est jamais utilisé, mais c'est pas plus grave que ça.

[Joel F]

encore mieux: ne pas utiliser de singleton