[ptr_container] plantage dans le destructeur

**poukill** · 21/01/2008, 12h09

Salut à tous !

Je suis en train d'implémenter pour m'exercer un pattern basé sur composite / fabrique. Tout marchait très bien jusqu'à ce que je veuille améliorer mon code en introduisant un ptr_list pour mieux gérer ma libération de mémoire. Et là c'est le drame.
LE problème est qu'il faut toujours passer directement le pointeur à la liste, du genre:

Code :

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

m_list.push_back( new Elements );

Et à un endroit du code, celà ne m'est pas possible. Je veux ajouter ma troupe de colvert à ma troupe de canard :

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
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
#include <iostream>
#include <limits>
 
#include "canard.h"
#include "fabrique.h"
 
struct SimulateurDeCanards
{
	SimulateurDeCanards()
	{
		std::cout << "Simulateur de Canard avec composite" << std::endl;
		m_fabrique_canard = new FabriqueDeComptage();
		m_fabrique_oie  =   new FabriqueDOies();
 
		m_troupe_de_canard  = new Troupe; // Creation d'un objet Composite
		m_troupe_de_colvert = new Troupe; // Creation d'un objet Composite
 
		// On remplit la troupe avec la fabrique appropriée
		m_troupe_de_canard->ajouter(m_fabrique_canard->creerMandarin());
		m_troupe_de_canard->ajouter(m_fabrique_canard->creerAppelant());
		m_troupe_de_canard->ajouter(m_fabrique_canard->creerCanardEnPlastique());
		m_troupe_de_canard->ajouter(m_fabrique_oie->creerOie());
 
		m_troupe_de_colvert->ajouter(m_fabrique_canard->creerColvert());
		m_troupe_de_colvert->ajouter(m_fabrique_canard->creerColvert());
		m_troupe_de_colvert->ajouter(m_fabrique_canard->creerColvert());
		m_troupe_de_colvert->ajouter(m_fabrique_canard->creerColvert());
 
		m_troupe_de_canard->ajouter(m_troupe_de_colvert); // Problème ICI lors de l'ajout du composite
	}
 
	~SimulateurDeCanards()
	{
		delete m_fabrique_canard;
		delete m_fabrique_oie;
 
		delete m_troupe_de_canard; // Ces deux lignes sont nécessaires
		delete m_troupe_de_colvert; // Ca plante plus si je les commente !!!
	}
 
	void simuler()
	{
		simuler(m_troupe_de_canard);
		simuler(m_troupe_de_colvert);
	}
 
	void simuler(Cancaneur * cancaneur)
	{
		cancaneur->cancaner();
	}
 
	FabriqueDeCanardsAbstraite * m_fabrique_canard;
	FabriqueDOies * m_fabrique_oie;
 
	Troupe *  m_troupe_de_canard;
	Troupe *  m_troupe_de_colvert;
};
 
int main()
{
	SimulateurDeCanards simulateur;
	simulateur.simuler();
 
	std::cout << "\nNous avons compté " << CompteurDeCouac::getCouacs() << " Couacs\n" << std::endl;
 
	std::cout << "Appuyez sur entrée pour continuer...";
	std::cin.ignore( std::numeric_limits<std::streamsize>::max(), '\n' );
 
	return 0;
}

Si quelqu'un a une idée, qui n'hésite surtout pas !

**Mat007** · 21/01/2008, 12h35

Salut,

Le boost::ptr_list devient propriétaire des éléments qu'on lui donne, donc soit tu en tiens juste compte en tu ne les re-détruits pas une seconde fois dans ton destructeur, soit tu utilises un conteneur STL 'normal' avec des boost::shared_ptr pour partager la propriété des éléments.

C'est un peu ce qu'explique la section Motivation de la documentation des ptr_list en fait.

MAT.

**poukill** · 21/01/2008, 12h42

Hum... Oui bien sûr. Merci Mat !
Damned, effectivement mon code marche maintenant, mais ça pose un sérieux problème de souplesse. Car les delete que tu mets (ou pas) dans ton destructeur vont dépendre directement de ton implémentation !

C'est moi où c'est pas génial génial ?

**Mat007** · 21/01/2008, 13h46

Dans ton cas ça ne semble pas tellement approprié en effet, si tu veux pouvoir conserver une référence directe sur certains éléments.

Cela dit en théorie l'intérêt du composite est que, une fois les éléments créés et l'assemblage fait, tu manipules tout à partir d'une seule référence sur le haut de l'arbre, et même pas un 'Troupe' mais bel et bien un 'Canard' (ou l'interface 'Oiseau' ou je sais pas quoi qu'il y aurait au-dessus et que à la fois 'Troupe' et 'Canard' implémenteraient).
Et donc du coup chaque 'Troupe' serait bien propriétaire de ses canards de manière transparente à l'utilisation.

Je sais pas si c'est très clair ce que je raconte...

MAT.

**poukill** · 21/01/2008, 14h57

Si si c'est évidemment très clair. L'intérêt du pattern composite est de manipuler le composite comme n'importe quel élément j'en suis bien conscient.
De ce fait, le code suivant:

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
 
struct Cancaneur
{
	Cancaneur() {}
	virtual ~Cancaneur() {}
	virtual void cancaner() = 0;
};
 
struct Troupe : public Cancaneur
{
	void ajouter( Cancaneur * cancaneur)
	{
		m_troupe.push_back(cancaneur);
	}
 
	void cancaner()
	{
		boost::ptr_list<Cancaneur>::iterator iter = m_troupe.begin();
		for(; iter != m_troupe.end(); ++iter)
		{
			iter->cancaner();
		}
	}
 
	boost::ptr_list<Cancaneur> m_troupe;
};

me paraissait une bonne idée car je ne me souciais plus de quoi que ce soit au niveau du destructeur. Maintenant, j'ai beaucoup perdu en souplesse d'utilisation si je veux ajouter un composite dans un composite... Car ptr_list prend le contrôle de tout.

Je crois que je vais repartir sur une std::list avec éventuellement des shared_ptr<> à l'intérieur... Qu'en penses-tu ?

**Mat007** · 21/01/2008, 15h19

Avec le boost::ptr_list tu peux toujours mettre un composite dans un composite, mais si y'a besoin à côté de garder des références sur les fils c'est peut-être plus délicat à utiliser sans se prendre les pieds dans le tapis.
C'est un choix !

Les boost::shared_ptr c'est pas la solution miracle non plus, si on ne fait pas gaffe on peut vite se retrouver avec des références circulaires...

MAT.

**poukill** · 21/01/2008, 15h23

Mouais...

En même temps c'est qu'un exemple pour moi ici, pour m'entraîner. Je vais revenir à un truc tranquille, à base de std::list et de pointeurs normaux!

Merci Mat pour le coup de main, et à bientôt !

**Mat007** · 21/01/2008, 15h29

Je ne sais pas si les pointeurs nus vont vraiment résoudre le problème.
Il faut bien que quelqu'un en soit propriétaire (et les détruise), donc si tu remplaces juste la boost::ptr_list par une std::list + delete dans le destructeur ça ne va rien changer...

MAT.

**poukill** · 21/01/2008, 15h30

Je viens d'avoir encore une interrogation (décidemment !

)

Du coup si j'implémente ma troupe comme ça :

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
struct Troupe : public Cancaneur
{
	Troupe() {}
	~Troupe()
	{
		std::list<Cancaneur *>::const_iterator iter = m_troupe.begin();
		for ( ; iter != m_troupe.end(); iter++)
		{
			delete *iter;
		}
	}
	Troupe (const Troupe &);
 
	void ajouter( Cancaneur * cancaneur)
	{
		m_troupe.push_back(cancaneur);
	}
 
	void cancaner()
	{
		std::list<Cancaneur *>::iterator iter = m_troupe.begin();
		for(; iter != m_troupe.end(); ++iter)
		{
			(*iter)->cancaner();
		}
	}
 
	std::list<Cancaneur *> m_troupe;
};

Je file aussi toute responsabilité à ma troupe, car tout est supprimé dans le destructeur! Finalement, y'a pas grand chose qui change, non ?

EDIT : post en même temps !

Effectivement ça va rien changer...

**Mat007** · 21/01/2008, 15h39

Au fait il faut que le destructeur de Cancaneur soit virtuel puisque justement tu détruits des Cancaneurs.

MAT.

**poukill** · 21/01/2008, 16h05

+1

**HanLee** · 22/01/2008, 00h50

Mouarf, c'est là que des fois on aimerait bien un Garbage Collector

.

**poukill** · 22/01/2008, 10h10

Oui c'est exactement ce que je me dis en ce moment...

Mais bon il y a toujours moyen de s'en sortir en encapsulant, encapsulant et encore encapsulant afin de donner des responsabilités à nos objets.

Les dernières nouvelles que j'avais n'étaient pas en faveur d'un GC pour C++ 0x, alors...

**JolyLoic** · 22/01/2008, 14h38

Si c'est ce que vous voulez, vous savez qu'il en existe, et des gratuits ?
http://www.hpl.hp.com/personal/Hans_Boehm/gc/

Effectivement, il semble que ça n'entrera pas dans C++0x. Je serais incapable d'analyser complètement le pourquoi.

Il y a des aspects politiques (des gens qui vivent en vendant des pointeurs intelligents, et qui trouvent qu'un GC ne sert à rien, par principe...). Il y a des aspects de planning. Il y a des aspects techniques, comme les questions de l'interaction de plusieurs GC dans un même programme (avec des DLL, par exemple), le statut peu clair des modificateurs permettant de paramétrer le GC sur un objet (font-ils ou pas partie du système de types...), le risque d'inutilisabilité pour une bibliothèque (et si le programme compile en mode non-gc ?),...

**poukill** · 22/01/2008, 16h38

Merci pour l'info Loïc.

Cependant je ne souhaite pas en utiliser pour l'instant.

**HanLee** · 23/01/2008, 01h41

Envoyé par JolyLoic

Si c'est ce que vous voulez, vous savez qu'il en existe, et des gratuits ?
http://www.hpl.hp.com/personal/Hans_Boehm/gc/

Effectivement, il semble que ça n'entrera pas dans C++0x. Je serais incapable d'analyser complètement le pourquoi.

Il y a des aspects politiques (des gens qui vivent en vendant des pointeurs intelligents, et qui trouvent qu'un GC ne sert à rien, par principe...). Il y a des aspects de planning. Il y a des aspects techniques, comme les questions de l'interaction de plusieurs GC dans un même programme (avec des DLL, par exemple), le statut peu clair des modificateurs permettant de paramétrer le GC sur un objet (font-ils ou pas partie du système de types...), le risque d'inutilisabilité pour une bibliothèque (et si le programme compile en mode non-gc ?),...

Je sais

.

Tu sais ce qu'il vaut par rapport au GC d'OCaml ?

**JolyLoic** · 23/01/2008, 03h14

Je n'ai hélas jamais eu le temps de tester ce GC, ni de tester sérieusement OCaml...

**Matthieu Brucher** · 23/01/2008, 20h54

Celui d'OCaml se base sur le fait que les pointeurs sont impairs ou qqch du style non ? Et les entiers ne sont codés que sur 31bits si je me souviens bien. Ca fait très artificiel comme système

**Alp** · 26/01/2008, 11h57

Pour poukill : si tu as un soucis pour l'effacement des pointeurs, tu peux peut-être construire un petit quelque chose autour de checked_delete sans passer par des shared_ptr. Par contre, il faut que tu détermines bien quand tel ou tel pointeur doit être supprimé, parce que bien qu'il y ait une vérification à la volée (checked

) il faudrait si possible ne pas repasser 10 fois sur le même pointeur. Ce n'est pas parce que tu as une bouée de sauvetage que tu vas te jeter à l'eau, n'est-ce pas ?

**HanLee** · 01/02/2008, 19h39

Envoyé par Matthieu Brucher

Celui d'OCaml se base sur le fait que les pointeurs sont impairs ou qqch du style non ? Et les entiers ne sont codés que sur 31bits si je me souviens bien. Ca fait très artificiel comme système

Oups, désolé pour le retard...

Alors oui les pointeurs sont distincts des entiers, j'crois qu'il utilise le bit de signe pour savoir.

Sinon, oui les entiers sont codés sur 31 bits sur une plateforme 31 bits, mais a priori c'est pas trop un problème, parce que je me dis que si on est amené à manipuler sans arrêt de entiers aussi grands, c'est que l'utilisation des entiers natifs n'est pas adaptée et qu'il faut passer à des trucs genre Bignum.

C'est en gros ce qui lui permet de ne pas avoir d'entiers boxés de manière simple.

Et Java il fait comment par exemple ?

[ptr_container] plantage dans le destructeur

Boost C++

Discussions similaires

Partager

Partager