Discussion :

[oodini]

Hello,

Soit une classe Pouet, et la liste STL suivante, accompagn�e de son it�rateur :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
list<Pouet*> dudule;
list<Pouet*>::iterator iter;

La m�moire pour les Pouet de la liste a �t� allou�e avec des new.

Quelle est la meilleure m�thode pour d�sallouer la m�moire ?

Pour l'instant, j'utilise une boucle qui fait :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
for (iter = pouetList.begin(); iter != pouet.end(); ++iter)
{
    Pouet* dudule = (Pouet*)*iter;
    delete dudule ;
}

Mais d'une part, le transtypage �tant � la C, j'aimeras le transformer en static_cast ou en dynamic_cast. Mais lequel utiliser ?
D'ailleurs, un transtypage est-il n�cessaire ?

Sinon, ne devrais-je tout simplement pas utiliser des auto_ptr pour mes Pouet ?
J'ai d�couvert �a il n'y a pas tr�s longtemps, et je ne sais pas toujours dans quels cas il faut l'utiliser.

Merci.

[Biozic]

Le transtypage n'est pas n�cessaire:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
for (iter = pouet.begin(); iter != pouet.end(); ++iter)
{
    delete *iter;
}

suffit (le type est inscrit dans le param�tre template de list).

Pour les auto_ptr, attention : cf. FAQ.

Sinon, les smart pointers de Boost (utilise shared_ptr) fonctionnent tr�s bien. Il existe aussi des conteneurs de pointeurs dans Boost, calqu�s sur la STL, mais je n'ai jamais test�.

[oodini]

Merci.

J'avais oubli� que je ne pouvais utiliser auto_ptr avec la STL.

[zais_ethael]

He ouais, c'est un peu stupide mais c'est ainsi.
Sinon, il faut d�ja te demander pourquoi tu stockes des pointeurs et pas des instances seules. Le cas le plus classique (et le moins contestable) serait celui o� tu fais du polymorphisme objet. Dans d'autre cas, il sera g�n�ralement possible de se passer des pointeurs.
Si tu n'as vraiment pas le choix, tu peux effectivement utiliser des shared_ptr, solution � laquelle je pr�f�rerais l'utilisation de ptr_container. Si tu n'as pas boost sous la main, un vector<*> est la seule solution mais uniquement si tu le place dans une classe/structure bien prot�g�e, m�me si ce n'est d�di� qu'� �a:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
struct vector_pouet {
   vector<pouet*> vec;
   ~vector_pouet () {...}
}

Ne va pas instancier directement un vector<*> comme variable locale, au sinon le mauvais code pas exception-safe te guete...

[oodini]

Je fais effectivement du polymorphisme.

Je ne comprend pas bien l'astuce de la structure, du vector, etc... ??

[zais_ethael]

Tu as d�ja entendu parler du RAII? Non? Et bien en gros, si tu as un code qui ressemble � �a:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
machin* x = new machin();
...
delete x;

ce n'est pas safe.
Pourquoi? Tout simplement parceque les trois petits points sont susceptibles de lancer une exception, et dans ce cas le delete ne sera pas effectu�. Si tu es en train de te dire que tu n'as qu'� faire attention � pas utiliser de fonctions lan�ant des exceptions c'est d�bile, tu ne connais pas toutes les fonctions et il est beaucoup plus simple de consid�rer que chaque ligne de C++ est susceptible d'en lancer. Il suffit alors d'employer un beau bar�me bien syst�matique pour que tout soit exception-safe.
Voila pourquoi on recommande l'utilisation de smart pointers � tout va, et pourquoi je te d�conseille d'instancier directement un vector<*> sur la pile. Rien qu'en encapsulant ton tableau dans une structure avec un destructeur correct tu n'auras aucun probl�me:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
void do_something() {
vector_pouet x;
...
//appel implicite du destructeur de vector_pouet, et donc destruction
//des objets pointés même si une exception est lancée
}

[Biozic]

utiliser des shared_ptr, solution � laquelle je pr�f�rerais l'utilisation de ptr_container

�a m'a donn� l'occasion de relire un peu la doc sur ptr_container, et c'est vrai que �a a l'air plus pertinent que shared_ptr quand on ne cherche qu'� stocker des pointeurs vers des classes polymorphiques. Je vais potasser.

[poukill]

Les ptr_container sont excellents pour avoir d�j� utilis� ptr_vector et ptr_map...

Bonne continuation !

[oodini]

Tu as d�ja entendu parler du RAII? Non? Et bien en gros, si tu as un code qui ressemble � �a:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
machin* x = new machin();
...
delete x;

ce n'est pas safe.

En l'occurrence, ma liste STL est une donn�e membre d'une classe A, et je la remplis de pointeurs dans une fonction membre.

Je lib�re les pointeurs allou�s dans le destructeur de la classe A.

Cela est-il suffisament safe ?

[zais_ethael]

Oui, tout � fait.
N�anmoins, si tu devais d�clarer plusieurs fois ce type de tableau, ce serait quand m�me mieux de chercher une solution plus r�utilisable.
PS: faire tr�s tr�s attention aux copies. Normalement, un objet polymorphe n'est jamais copiable, donc toute classe qui g�re le cycle de vie d'un de ces objets devrait toujours �tre d�clar�e non copiable. Pour rappel:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
class machin {
...
private:
machin(const machin&);
machin& operator=(const machin&);
...
}

[yan]

PS: faire tr�s tr�s attention aux copies. Normalement, un objet polymorphe n'est jamais copiable, donc toute classe qui g�re le cycle de vie d'un de ces objets devrait toujours �tre d�clar�e non copiable.

pourquoi??

[M�dinoc]

Parce qu'on pourrait "copier" un objet d'une classe fille en objet de la classe m�re, ce qui signifie g�n�ralement des probl�mes.

La plupart des objets polymorphes "copiables" sont en fait "clonables": Ils ont une fonction membre virtuelle clone() et leur constructeur de copie est private ou protected...

[zais_ethael]

Avec une classe A et une classe B qui en h�rite:
Construction d'un objet � partir d'un objet polymorphe:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
A* x = ...;
A* y = ??(x);

Question: comment on d�termine la classe � construire??

Utilisation de l'op�rateur = :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
A* x = ...;
A* y = ...;
(*y) = (*x);

Tu crois vraiment que �a peut fonctionner? Les classes A et B n'occupent pas le m�me espace m�moire, et l'op�rateur = ne peut pas modifier l'espace allou�.

Conclusion => un objet polymorphe ne peut �tre copi� (il peut �ventuellement �tre clon�, mais la c'est � toi de faire ta propre hi�rarchie de classes clonables).

Si une classe g�re le cycle de vie d'une donn�e point�e, elle doit dupliquer ces donn�es lors de la copie c'est logique (comme tous les conteneurs de la stl le font), mais si ce n'est pas possible il faut interdire la copie. Eventuellement, on peut mettre en place des modes de fonctionnement plus exotiques, comme celui d'auto_ptr, mais ce ne serait pas tr�s user-friendly, la personne qui utiliserait la classe devrait faire attention aux copies pour ne pas se retrouver avec des donn�es incoh�rentes.

Tu commences � comprendre pourquoi certains (tels que moi) disent que le C++ n'est pas un langage orient� objet?

[yan]

Parce qu'on pourrait "copier" un objet d'une classe fille en objet de la classe m�re, ce qui signifie g�n�ralement des probl�mes.

La plupart des objets polymorphes "copiables" sont en fait "clonables": Ils ont une fonction membre virtuelle clone() et leur constructeur de copie est private ou protected...

Ok, merci. Je pensais qu'il pouvait y avoir une autre raison

Si une classe g�re le cycle de vie d'une donn�e point�e, elle doit dupliquer ces donn�es lors de la copie c'est logique (comme tous les conteneurs de la stl le font), mais si ce n'est pas possible il faut interdire la copie. Eventuellement, on peut mettre en place des modes de fonctionnement plus exotiques, comme celui d'auto_ptr, mais ce ne serait pas tr�s user-friendly, la personne qui utiliserait la classe devrait faire attention aux copies pour ne pas se retrouver avec des donn�es incoh�rentes.

Tu commences � comprendre pourquoi certains (tels que moi) disent que le C++ n'est pas un langage orient� objet?

ouawow.. pas du tout