SmartPointer non fonctionnel

Version imprimable

Voir 40 message(s) de cette discussion en une page

Bonjour � tous,

J'ai d�veloppez il y a quelques temps une classe de smart pointer de type :
Code:

1 2 3 4 5 6 template <class T> class CSmartPointer { T *m_Pointer; int *m_Counter; };
J'ai d�j� eu l'occasion de faire quelques tests, il "semblerait" qu'ils soient fonctionnels. J'ai pu lire que dans mon cas de figure seul les r�f�rences circulaires emp�ch�es les smarts pointers de fonctionner. Or j'ai d�couvert un bug plut�t "�trange" (tout du moins incompris de moi). Voil� le d�tail de ce qui se passe :
Code:

1 2 3 4 5 6 class CSceneManager{ //... bool ReadScene(std::string const &Filename); bool ReadScene(CNodePtr Root); CNodePtr m_Root; }
Il faut savoir que CNodePtr est donc de type CSmartPointer<CNode> (CNode n'�tant pas important ici). m_Root est initialis� a NULL par d�faut et le compteur � 1. Maitenant dans la fonction ReadScene :
Code:

1 2 3 4 5 6 7 8 9 bool CSceneManager::ReadScene(std::string const &Filename) { //... // Load the scene : CNodePtr NodeTmp = Loader->LoadScene(Filename); // compteur à 1!! bool b = ReadScene(NodeTmp); // compteur à 2 return b; // compteur à 0 }
Une petite explication s'impose, Loader est une instance de classe permettant de charger des sc�nes, la fonction LoadScene renvoie un CNodePtr correspondant � la sc�ne charg�e. Et enfin :
Code:

1 2 3 4 5 6 bool CSceneManager::ReadScene(CNodePtr Root) { //... m_Root = Root; //compteur à 3 return true; }
R�sultat l'objet est d�truit... et je bloc dessus depuis un bon moment d�j� alors que �a � l'air idiot:aie: (mais bon c'est toujours comme �a)
Si vous avez besoin de plus de code (CSmartPointer, fonctions...) n'h�sitez pas � demander...

Merci d'avance et bonne fin de journ�e

02/03/2008, 20h09
Mat007

Salut,

Plut�t que de perdre du temps � (mal) refaire la roue pourquoi tu n'utilises pas boost ?

MAT.
02/03/2008, 20h49
babar63

Citation:

Plut�t que de perdre du temps � (mal) refaire la roue

Cette argument est souvent cit�, personnellement je fais partie de ceux qui aiment "refaire la roue", la question n'est pas de la refaire (bien ou mal), je continuerai d'ailleurs d'utiliser boost, mais le but est d'apprendre... ce n'est donc pas une perte de temps � mon avis (mais bon apr�s c'est personnel).

J'utilise ma classe dans ce projet afin de la tester tout simplement...
02/03/2008, 22h35
Mat007

Ok, mettons...

Il faudrait sans doute en effet le code de CSmartPointer pour savoir exactement ce qui se passe.

MAT.

Voila un code plus complet sur ma classe mais je ne vois toujours pas d'erreur :evilred:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
template <class T>
class CSmartPointer
{
public:
 
	// Constructor :
	CSmartPointer(T *Pointer = NULL);
	CSmartPointer(CSmartPointer<T> const &SmartPointer);
 
	// Destructor :
	~CSmartPointer();
 
	// Operator :
	CSmartPointer<T> & operator = (CSmartPointer<T> const &SmartPointer);
	//...
 
	//....
 
private:
 
	T		*m_Pointer;			// Pointer on the object
	int		*m_Counter;			// Counter on the object pointed
};

Et le .inl mais toujours rien de compliqu� :

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
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
//Constructor (1param) :
template <class T>
inline CSmartPointer<T>::CSmartPointer(T *Pointer)
{
	// Initialisation :
	m_Pointer = Pointer;
	m_Counter = new int(1);
}
 
//Copy constructor :
template <class T>
inline CSmartPointer<T>::CSmartPointer(CSmartPointer<T> const &SmartPointer)
{
	// Copy :
	m_Pointer = SmartPointer.m_Pointer;
	m_Counter = SmartPointer.m_Counter;
 
	// Incrementation :
	++(*m_Counter);
}
 
//Destructor :
template <class T>
inline CSmartPointer<T>::~CSmartPointer()
{
	// Decrementation :
	if( --(*m_Counter) == 0 )
	{
		delete m_Pointer;
		delete m_Counter;
	}
}
 
//Operator = :
template <class T>
inline CSmartPointer<T> & CSmartPointer<T>::operator = (CSmartPointer<T> const &SmartPointer)
{
	Assert( (this != &SmartPointer) );
 
	// Decrementation :
	if( --(*m_Counter) == 0 )
	{
		delete m_Pointer;
		delete m_Counter;
	}
 
	// Copy :
	m_Pointer = SmartPointer.m_Pointer;
	m_Counter = SmartPointer.m_Counter;
 
	// Incrementation :
	++(*m_Counter);
 
	return *this;
}

Je passe ici les d�tails sur les op�rateurs de casts, pr�dicat etc...

Mais ce qui me surprend le plus c'est � ce niveau la :

Code:

CNodePtr NodeTmp = Loader->LoadScene(Filename); // compteur à 1!!

Le compteur devrait �tre � deux (je suppose) mais je ne trouve pas l'erreur :cry:

03/03/2008, 06h34
vdumont
Tu peux montrer un main et ton Loader pour qu'on voit un cas typique d'utilisation?

Note:
Code:

1 2 3 // Copy : m_Pointer = SmartPointer.m_Pointer; m_Counter = SmartPointer.m_Counter;
Ici j'esp�re que t'es conscient que tu ne fais pas une copy v�ritable mais tu fais seulement pointer tes pointeurs sur les m�mes addresses que SmartPointer ?

(Aussi, ourquoi utiliser un pointeur sur un entier au lieu de tout simplement utiliser un entier? Je vois pas l'int�r�t dans ton cas.)
03/03/2008, 09h38
Mat007

Citation:

Envoy� par babar63

Mais ce qui me surprend le plus c'est � ce niveau la :

Code:

CNodePtr NodeTmp = Loader->LoadScene(Filename); // compteur à 1!!

Le compteur devrait �tre � deux (je suppose) mais je ne trouve pas l'erreur :cry:

Pourquoi � 2 ? Il n'y a plus qu'une r�f�rence, port�e par NodeTmp, donc 1 me semble la bonne valeur. Ou j'ai rat� un truc ?

Citation:

Envoy� par vdumont

Pourquoi utiliser un pointeur sur un entier au lieu de tout simplement utiliser un entier? Je vois pas l'int�r�t dans ton cas.

Pour pouvoir partager le compteur entre toutes les copies du "smart pointer".

Sinon l� comme �a en premi�re lecture je ne vois trop rien qui puisse poser probl�me (enfin � part cet Assert qui n'a pas l'air terrible mais bon c'est pas le probl�me � la limite).

MAT.
03/03/2008, 10h33
corrector
Citation:
Envoy� par vdumont

Note:

Code:

1 2 3 // Copy : m_Pointer = SmartPointer.m_Pointer; m_Counter = SmartPointer.m_Counter;

Ici j'esp�re que t'es conscient que tu ne fais pas une copy v�ritable mais tu fais seulement pointer tes pointeurs sur les m�mes adresses que SmartPointer ?
Je pense que :
1. il est conscient de copier les pointeurs
2. le comportement de la classe SmartPointer est model� sur celui d'un pointeur C++
3. SmartPointer n'est pas un pointeur (c'est une classe), SmartPointer n'est pas tr�s intelligente (c'est juste un pointeur et un compteur de r�f�rence manipul�s ensemble), SmartPointer est donc ce qu'on appelle un smart-pointer
Comme c'est un pointeur � propri�t� partag�e avec compteur de r�f�rences, il vaudrait mieux l'appeler SharingPointer ou RefCountedPointer AMHA.

Citation:

Envoy� par vdumont

(Aussi, pourquoi utiliser un pointeur sur un entier au lieu de tout simplement utiliser un entier? Je vois pas l'int�r�t dans ton cas.)

Parce que si chaque instance a une copie de l'entier �a ne risque pas de marcher!

Citation:
Envoy� par babar63
Code:

1 2 3 4 5 6 7 template <class T> class CSmartPointer { public: // Constructor : CSmartPointer(T *Pointer = NULL);
C'est volontairement que tu d�clare une conversion implicite de T* vers CSmartPointer?

Si ce n'est pas le cas, ajoute le mot-clef "explicite".
Citation:
Envoy� par babar63
Code:

1 2 3 4 5 6 7 template <class T> inline CSmartPointer<T>::CSmartPointer(T *Pointer) { // Initialisation : m_Pointer = Pointer; m_Counter = new int(1); }
Il est idiomatique d'utiliser la liste d'initialisation, m�me quand �a ne change pas la signification du code, comme ici (les membres ont tous un type de base).
Citation:
Envoy� par babar63
Code:

1 2 3 4 5 6 7 //Copy constructor : template <class T> inline CSmartPointer<T>::CSmartPointer(CSmartPointer<T> const &SmartPointer) { // Copy : m_Pointer = SmartPointer.m_Pointer; m_Counter = SmartPointer.m_Counter;
Idem.
Citation:
Envoy� par babar63
Code:

1 2 3 4 5 6 7 8 9 // Incrementation : ++(*m_Counter); } //Operator = : template <class T> inline CSmartPointer<T> & CSmartPointer<T>::operator = (CSmartPointer<T> const &SmartPointer) { Assert( (this != &SmartPointer) );
Pourquoi assert? Tu veux interdire l'auto-affectation?

Citation:

Envoy� par babar63

Mais ce qui me surprend le plus c'est � ce niveau la :

Code:

CNodePtr NodeTmp = Loader->LoadScene(Filename); // compteur à 1!!

Le compteur devrait �tre � deux (je suppose) mais je ne trouve pas l'erreur

Des d�tails sur LoadScene?

03/03/2008, 11h39
Emmanuel Deloget
Citation:

Envoy� par corrector

Pourquoi assert? Tu veux interdire l'auto-affectation?

Pour le coup, il vaut mieux - car la fonction commence par d�cr�menter le compteur avant de le r�initialiser avec la nouvelle valeur. Ce qui est probl�matique d'ailleurs, parce que l'assert est vir� si on quitte le mode debug. Il faut un test - pas un assert (d'autant plus que l'auto-affectation est un idiome valide; pas le peine de planter le programme pour �a):
Code:

1 2 3 4 5 template <class T> inline CSmartPointer<T> & CSmartPointer<T>::operator = (CSmartPointer<T> const &SmartPointer) { if (&SmartPointer == this) return *this;
Pour comprendre ton probl�me, met un point d'arr�t sur chaque d�cr�mentation du compteur, et v�rifie la stack d'appel au moment ou tu tombe sur le point d'arr�t. Tu sauras alors qui tente de d�truire le smart pointer, et tu auras plus de billes pour comprendre ce qui se passe.

Merci pour vos r�ponses,

Citation:

Tu peux montrer un main et ton Loader pour qu'on voit un cas typique d'utilisation

Pour le main je peux en effet mais je ne vois pas l'int�r�t, puisque le main se contente d'appeler la fonction ReadScene(...). Peut �tre le loader mais je ne pense pas que le probl�me soit l�...
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 // Initalisation : Document Doc; if( !Doc.Read( Filename.data() ) ) { SET_ERROR_CODE(INVALID_PARAMETER); return CNodePtr(); } // Obtain the root element("scene") : Element RootElem = Doc.RootElement(); // Root node : CSeparator * RootNode = new CSeparator(); // Map for the nodes : std::map<std::string, CNodePtr> NodesMap; // Extract nodes : if( !LoadCameras(RootElem,NodesMap) ) return CNodePtr(); if( !LoadLights(RootElem,NodesMap) ) return CNodePtr(); if( !LoadMaterials(RootElem,NodesMap) ) return CNodePtr(); if( !LoadTransforms(RootElem,NodesMap) ) return CNodePtr(); if( !LoadModels(RootElem,NodesMap) ) return CNodePtr(); // Extract scene graph : Element GraphElem = RootElem.FirstChild( "graph" ); std::list<Element> NodeList = GraphElem.Children( "node" ); for(std::list<Element>::iterator iter=NodeList.begin(); iter!=NodeList.end(); ++iter) { if( !LoadChild(RootNode,(*iter),NodesMap) ) return CNodePtr(); } // Scene loaded : return RootNode;
Si quelque chose n'est pas clair dans ce code n'h�sitez pas � demander.

Citation:

Pourquoi � 2 ? Il n'y a plus qu'une r�f�rence, port�e par NodeTmp, donc 1 me semble la bonne valeur

La fonction pour loader renvoyant un CNodePtr je pensais qu'un objet temporaire �tait cr�e... plus l'op�rateur = �a aurait fait 2. En tout cas ce qui est s�r c'est que deux destructeurs sont appel�s a la fin de la fonction (v�rifi� au debug).

Citation:

C'est volontairement que tu d�clare une conversion implicite de T* vers CSmartPointer

Oui en effet c'est volontaire pourquoi ce n'est pas bon?

Citation:

Il est idiomatique d'utiliser la liste d'initialisation, m�me quand �a ne change pas la signification du code, comme ici

La en revanche ce n'est pas volontaire, j'ai oubli� :oops:

Citation:

Pour comprendre ton probl�me, met un point d'arr�t sur chaque d�cr�mentation du compteur, et v�rifie la stack d'appel au moment ou tu tombe sur le point d'arr�t. Tu sauras alors qui tente de d�truire le smart pointer, et tu auras plus de billes pour comprendre ce qui se passe

Justement je l'ai fait! Deux destructeurs sont appel� � la fin de ma fonction :

Code:

bool CSceneManager::ReadScene(std::string const &Filename)

Le compteur atteint 0, l'objet est d�truit alors qu'il devrait �tre stock� dans m_Root...

Je m'excuse d'avance pour le code, si il n'est pas clair. Le projet �tant suffisamment important pour que je ne veuille pas vous d�courager en affichant tout le code (ce qui en plus n'avancera pas forc�ment les choses). En tout cas merci pour votre aide :D

J'ai trouv� un exemple qui marche parfaitement (mais �a ne r�sout pas mon probl�me) :
Code:

1 2 3 4 5 6 7 8 9 bool CSceneManager::ReadScene(std::string const &Filename) { //... // Load the scene : CNodePtr NodeTmp(new CSeparator());//Loader->LoadScene(Filename); //Compteur à 1 bool b = ReadScene(NodeTmp); //Compteur à 2 return b; //Compteur à 1 }
Les commentaires sur les compteurs repr�sentent le nombre de r�f�rences point�es APRES la ligne comment�e. Un seul destructeur est appel� ici � la fin de ma fonction (NodeTmp) donc aucun probl�me... l'objet n'est pas d�truit

Si ReadScene() prend un CNodePtr en param�tre, le destructeur de CNodePtr devrait �tre appel� deux fois: Une fois dans la fonction ReadScene(), une fois en fin de bloc.

Si tu veux h�ter la destruction, tu peux faire ceci pour essayer de mieux d�boguer:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 bool CSceneManager::ReadScene(std::string const &Filename) { //... bool b; // Load the scene : { CNodePtr NodeTmp(new CSeparator());//Loader->LoadScene(Filename); //Compteur à 1 b = ReadScene(NodeTmp); //Compteur à 2 }// Compteur à zéro, tout détruit. return b; }

Je viens de penser � quelque chose : ton op�rateur=() est incorrect, car il ne r�gle pas le probl�me de l'assignation � soi-m�me. Tu dois aussi v�rifier que pointeur et compteur ne pointent pas au m�me endroit.

De mani�re plus g�n�rale, tu devrais inversion les deux op�rations (decr, delete) et (affectation, incr):
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 template <class T> inline CSmartPointer<T> & CSmartPointer<T>::operator = (CSmartPointer<T> const &SmartPointer) { int* old_counter = m_Counter; T* old_ptr = m_Pointer; m_Counter = SmartPointer.m_Counter; m_Pointer = SmartPointer.m_Pointer; ++(*m_Counter); if( --(*old_counter) <= 0 ) { delete old_ptr; delete old_counter; } return *this; }
De cette mani�re, tu t'affranchis des probl�mes li�s � l'auto-affectation.

Note: ton Root viens de l'objet Doc que tu cr�e dans ReadScene. Il sera d�truit en sortant de cette fonction. (1 objet dans Doc, un object dans ReadScene; ces deux instances ont une port�e automatique).

03/03/2008, 14h38
M�dinoc

Je trouve cet op�rateur = un peu compliqu�.
Un copy-swap poserait sans doute moins de probl�mes...
03/03/2008, 14h50
corrector
Citation:

Envoy� par Emmanuel Deloget

Je viens de penser � quelque chose : ton op�rateur=() est incorrect, car il ne r�gle pas le probl�me de l'assignation � soi-m�me. Tu dois aussi v�rifier que pointeur et compteur ne pointent pas au m�me endroit.

Tu veux dire qu'ajouter le test d'auto-affectation suivant � son operator= n'est pas suffisant?
Code:

1 2 if (this == &rhs) return;
Il me semble qu'il est suffisant � prot�ger son code. Peux-tu montrer un exemple qui pose probl�me?

Citation:

Envoy� par Emmanuel Deloget

De mani�re plus g�n�rale, tu devrais inversion les deux op�rations (decr, delete) et (affectation, incr):

Oui, c'est la meilleur solution (plus g�n�rale).

Citation:

Si tu veux h�ter la destruction, tu peux faire ceci pour essayer de mieux d�boguer:

Merci, en effet �a m'a aid�, l'erreur ne se trouve pas du tout ici... j'ai confondu le destructeur de "Loader" (qui est de type CSmartPointer<ILoader>) avec celui de "NodeTmp" :aie:

Voila un exemple de ce qui plantait :
Code:

1 2 3 4 5 6 7 8 9 10 class CSceneManager{ //... bool AddCamera(CCameraPtr Camera); //... bool ReadScene(std::string const &Filename); bool ReadScene(CNodePtr Root); CNodePtr m_Root; TScenePtr m_Scene; std::vector<CCameraPtr> m_Cameras; }
m_Scene et m_Cameras sont remplis lors de la lecture de mon graphe de sc�ne via une fonction virtuelle pure :

Code:

virtual void Update(CSceneManager &SceneManager) = 0;

Maintenant voila la fonction Update redefinis pour une camera :
Code:

1 2 3 4 void CCamera::Update(CSceneManager &SceneManager) { SceneManager.AddCamera(this); }
La cam�ra est donc d�j� point� par CNodePtr, lorsque j'appelle AddCamera(this), j'appelle le constructeur de CSmartPointer et d�finit le compteur � 1 alors qu'il devrait �tre � deux....
La seule solution que j'ai trouv� :
Code:

1 2 3 4 void CCamera::Update(CSceneManager &SceneManager) { SceneManager.AddCamera( new CCamera(*this) ); }
Citation:

Je viens de penser � quelque chose : ton op�rateur=() est incorrect, car il ne r�gle pas le probl�me de l'assignation � soi-m�me

Justement c'est la raison pour laquelle j'avais un assert, je voulais simplement interdire l'auto-affectation sans surcharger avec un test... D'ailleurs je ne comprend pas vraiment pourquoi utiliser un test pour �viter l'auto-affectation dans l'operateur =, celle-ci a-t-elle une signification? (moi je ne voit pas l'utilit� :roll:)
Encore merci pour votre aide

03/03/2008, 17h42
vdumont
Citation:

Justement c'est la raison pour laquelle j'avais un assert, je voulais simplement interdire l'auto-affectation sans surcharger avec un test... D'ailleurs je ne comprend pas vraiment pourquoi utiliser un test pour �viter l'auto-affectation dans l'operateur =, celle-ci a-t-elle une signification? (moi je ne voit pas l'utilit� :roll:)
Encore merci pour votre aide

Parce qu'il faut que tu fasses attention aux programmeurs qui pourrait utiliser ta classe. Exemple typique:
Code:

1 2 3 4 Class Widget {...} Widget w; w = w; // stupide mais légal
Des fois c'est subtile et involontaire:

Code:

*px = *py; // self-assignment si les 2 pointent au même endroit
03/03/2008, 17h55
babar63

Oui mais dans ce cas pourquoi ne pas laisser l'assert, pour justement pr�venir d'une telle faute? Ce qui me g�ne c'est de laisser un test JUSTE pour pr�venir les futures fautes de programmations :roll:
03/03/2008, 18h31
vdumont

Si ma m�moire est bonne l'assertion va halter l'ex�cution de ton programme dans le cas d'une auto-affectation. Si c'est ce que tu veux d'accord, mais sinon le programme peut tr�s bien continuer son ex�cution normale en g�rant l'auto-affectation en retournant *this.

Voir 40 message(s) de cette discussion en une page