Discussion :

[elekis]

bonjour,

j'ai un petit probleme d'ordre de destruction. j'ai deux classe statique singletons. comme ceci

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
 
class CPictureManager{
 
 
	private:
		CPictureManager(){};
		...
	public:
		static CPictureManager& GetInstance(){
			static CPictureManager Pict;
			return Pict;
		}	
	          .... autre fonctions....
		virtual ~CPictureManager();
 
};

ainsi qu'une autre basé qui me sert de gestionnaire de memoire.

seul hic, il me detruit d'abord la classe static du gestionnaire de memoire ce qui est assez embetant car il me dit qu'il y a des memory leaks qui n'ont aps été detruit. c'est memroy leaks feasant partie du ~CPictureManager.

comment faire pour detruire d'abord CPictureManager et pis CMemoryLeaks ??


merci


a++



seule hic c'est qu'il me detruit l'autre classe en premier alors que celle ci

[Higestromm]

Tu est sur que ton GetInstance n'alloue pas de mémoire ?

Sinon tu dit dans le destructeur de CPictureManager de detruire CMemoryLeaks.

[elekis]

Code :

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

1
2
3
4
5
 
static CPictureManager& GetInstance(){
			static CPictureManager Pict;
			return Pict;
		}

je ne vois aps ou.

par contre. dans quelle ordre sont detruit les obj statiques, dans l'odre qu'il sotn construit (cad du premier appel) ou bien dans l'ordre inverse??µ


merci


a+

[Higestromm]

Bah normalement ton programme ne devrais pas dépendre de ca...

A tu penser a mettre en statique un CMemoryLeaks dans ta class CPictureManager ?

Ou bien peut etre que tu devrais utiliser des SmartPointers ?

[Herode]

dans quelle ordre sont detruit les obj statiques, dans l'odre qu'il sotn construit (cad du premier appel) ou bien dans l'ordre inverse??

3.6.3 Termination [basic.start.term]
1 Destructors (12.4) for initialized objects of static storage duration (declared at block scope or at namespace
scope) are called as a result of returning from main and as a result of calling exit (18.3). These objects
are destroyed in the reverse order of the completion of their constructor or of the completion of their
dynamic initialization. If an object is initialized statically, the object is destroyed in the same order as if the
object was dynamically initialized. For an object of array or class type, all subobjects of that object are
destroyed before any local object with static storage duration initialized during the construction of the subobjects
is destroyed.

NB : ce qui compte, c'est l'ordre dans lequel les constructeurs des objets statiques ont été achevés (et non pas celui dans lequel ils ont été appelés). En général, ça ne fait pas de différence, mais il y a des exceptions à tout.

Cela dit, il peut être très délicat de savoir exactement dans quel ordre sont construits les objets statiques. Le plus sûr est sans doute , comme le signale Higestromm, de ne pas faire dépendre son programme de ça.

[Jan Rendek]

Il est possible de mettre en place un système de longévité pour les objets globaux, afin d'assurer leur destruction dans un certain ordre (en utilisant les fonctions du genre atexit)
Néanmoins, cela présuppose que les globaux soient alloué de manière dynamique.

[Sivrît]

Je n'avais jamais vu de singleton implémenté comme ça...

Code :

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

1
2
3
4
static CPictureManager& GetInstance(){
         static CPictureManager Pict;
         return Pict;
      }

Utiliser un objet déclaré dans une fonction me semble assez cavalier (ça revient à violer les règles de visibilité). Je serais plutôt passé par le new usuel afin d'avoir la maitrise de la construction/destruction. Si c'est un pointeur, le destructeur de ton memory manager pourra le détruire lui-même ou signaler qu'il n'en a plus besoin et ainsi eviter les incohérences.


Sinon, comment appelle-t-on le fait d'avoir un pointeur ou une référence sur un objet qui n'existe plus ? Je me demande si ça n'est pas aussi compté comme une memory leak (sinon pas de new = pas de fuite) et ça serait cohérent avec le message : le "static CPictureManager Pict;" est détruit à la fin, ce qui appelle ~CPictureManager et là on s'apperçoit que CMemoryLeaks a encore une référence sur l'objet en train d'être détruit.
Le problème serait donc l'inverse.

[Jan Rendek]

Je n'avais jamais vu de singleton implémenté comme ça...

Code :

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

1
2
3
4
static CPictureManager& GetInstance(){
         static CPictureManager Pict;
         return Pict;
      }

Utiliser un objet déclaré dans une fonction me semble assez cavalier (ça revient à violer les règles de visibilité).

C'est la procédure usuelle, documentée dans de nombreux ouvrages. Je ne vois pas en quoi cela viole une règle de visibilité.

[Sivrît]

C'est la procédure usuelle, documentée dans de nombreux ouvrages.

oups

Je ne vois pas en quoi cela viole une règle de visibilité.

Alors disons que ça heurte mon sens de l'esthétique. Déclarer un objet dans une méthode à la seule intention du reste du monde... Pour moi il devrait rester local et j'aurais plutôt déclaré "Pict" au niveau de la définition de la classe. C'est stupide ou c'est un troll ?

[Higestromm]

j'aurais plutôt déclaré "Pict" au niveau de la définition de la classe. C'est stupide ou c'est un troll ?

J'avoue que j'ai tendance à faire pareille... Je pense que c'est plus une histoire de gout et de couleur qu'une histoire de bien ecrire / mal ecrire.

[Luc Hermitte]

Loki et ACE sont tes amis. Voidseer a évoqué le principe sous-jacent à leur solutions.

[elekis]

en fiat, j'ai appris ce singletons ici

http://loulou.developpez.com/tutorie...eur3d/partie1/

en attendant de me mettre au pointeur intellignet.

PS, pour le probleme, je l'ai plus ou moins resolu en netoyant par moi meme le ManagerPict.


merci

a+++

[Jan Rendek]

Pour moi il devrait rester local et j'aurais plutôt déclaré "Pict" au niveau de la définition de la classe. C'est stupide ou c'est un troll ?

Ce n'est pas stupide en soi. Le principal problème avec un singleton, c'est de le détruire. Aucune partie de l'application ne prend la responsabilité de le créer, donc aucun client n'est responsable de sa destruction.
Il se trouve que de déclarer l'instance comme variable locale statique d'une fonction permet justement d'éviter de se poser des problème concernant la durée de vie du singleton.
Sa durée de vie est régentée par les règles qui s'applique au variables statiques de fonction, et c'est le compilateur qui se charge de détruire l'instance à la sortie du programme.
C'est AMA principalement ce qui rend cette idiome populaire pour implanter un singleton.

[Aurelien.Regat-Barrel]

j'aurais plutôt déclaré "Pict" au niveau de la définition de la classe. C'est stupide ou c'est un troll ?

J'avoue que j'ai tendance à faire pareille... Je pense que c'est plus une histoire de gout et de couleur qu'une histoire de bien ecrire / mal ecrire.

Passer par une fonction statique plutôt qu'une variable statique me semble plus évolutif. Par exemple, si demain l'accès à l'instance doit être thread safe, tu peux facilement modifier GetInstance(). Si c'est directement Pict qui est référencé, ça se complique... C'est un peu un débat variable globale vs fonction globale.

[Higestromm]

j'aurais plutôt déclaré "Pict" au niveau de la définition de la classe. C'est stupide ou c'est un troll ?

J'avoue que j'ai tendance à faire pareille... Je pense que c'est plus une histoire de gout et de couleur qu'une histoire de bien ecrire / mal ecrire.

Passer par une fonction statique plutôt qu'une variable statique me semble plus évolutif. Par exemple, si demain l'accès à l'instance doit être thread safe, tu peux facilement modifier GetInstance(). Si c'est directement Pict qui est référencé, ça se complique... C'est un peu un débat variable globale vs fonction globale.

Bah en fait j'aurais déclarer ma variable statique dans ma class en private et j'y aurais acceder via une fonction statique. Donc je n'aurais pas rencontrer ce problème.

[Aurelien.Regat-Barrel]

Af d'accord. Ben alors dans ce cas, ta variable private est un détail d'implémentation, si elle peut ne pas figurer dans le .h, c'est mieux