Discussion :

[Bakura]

vector <Sprite *>::iterator s1;

for (s1 = m_vSprites.begin() ; s1 != m_vSprites.end() ; ++s1
{
delete (*s1);
}

m_vSprites.clear();

C'est mieux ? ^^

Hum je vais essayer de voir ton tutoriaux sur les pointeurs intelligents, c'est vrai que si j'ai plus à m'occuper à faire les delete de tous mes pointeurs (c'est bien ça l'intêret ?), ce sera super ^^.

EDIT : ah oui, pendant que j'y suis... Sur mon livre de C++ (enfin dans mes souvenirs ^^), ils disent que l'itérateur est un pointeur.

Donc que dans l'exemple plus haut s1 est un pointeur vers un élément de la liste. Mais alors pourquoi j'ai à fait lors d'appels de fonctions par exemple de d'abord déréferencer le pointeur et après en plus faire le -> (*s1)->Fonction(). le s1->Fonction() ne fonctionne pas...

Ce sont des pointeurs de pointeurs ?

EDIT 2 : oh que je suis con, ça doit être des pointeurs de pointeurs en effet vu que c'est un vector de pointeur ^^.

[Laurent Gomila]

C'est mieux ? ^^

Oui.

oh que je suis con, ça doit être des pointeurs de pointeurs en effet vu que c'est un vector de pointeur ^^

Oui.
Par contre attention : les itérateurs se comportent comme des pointeurs, mais n'en sont pas forcément. Dans le cas de std::vector<>::iterator c'est parfois le cas, mais ce n'est pas garanti. Enfin de toute façon ce n'est qu'un détail d'implémentation.

[ash.ice.loky]

Pour faire simple le fonctionnement des pointeur intelligent est le suivant :

(la STL en possede : auto_ptr)

Code :

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

1
2
 
PointeurIntelligent <Objet> Pio = new Objet (parametres) ;

a partir de la le delete sera automatique
avec des containers, par exemple un vector de sprites:

Code :

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

1
2
3
4
5
6
 
vector < PointeurIntelligent<Sprite> > vSprite ;
 
vSprite.push_back ( new Sprite (parametres)) ;
vSprite.push_back ( new Sprite (parametres)) ;
vSprite.push_back ( new Sprite (parametres)) ;

et c'est tout, lorsque tout sera inutile, ils seront delete automatiquement.

Dans les Pointeurs Intelligents les plus connus sont :
- loki
- Boost (un tuto est dispo sur le site)

[Matthieu Brucher]

Les auto_ptr ne sont pas compatibles avec les conteneurs, attention

[Médinoc]

Ah oui, d'après ce dont je me souviens, la lecture retirerait l'objet du conteneur (à supposer que ça compile sans violer la const-correctness...)

Les shared_ptr de boost (avec comptage de références, c'est ça?) marchent, par contre, non ?

[Matthieu Brucher]

Oui, les pointeurs de Boost implémentent un compteur de référence ou empêche la copie, donc pas de souci.
Le pb des auto_ptr, c'est que la copie transfert la responsabilité, et lors des copies pour comparer et compagnie, on perd l'objet.

[ash.ice.loky]

en effet a noter aussi qu'il n'aime pas le passage par copie sur une fonction pour le meme probleme de transmission de responsabilite.

[Médinoc]

Donc, en fait, auto_ptr, ça veut juste dire "je fais automatiquement un delete dans le destructeur"...
Je pense que l'auto_ptr ne devrait pas être copiable, avec tous ces inconvénients...

[Luc Hermitte]

Les std::auto_ptr<> sont parfaits pour ce pour quoi ils sont faits: implémenter une sémantique de déplacement et assumer des responsabilités passagères.

Il n'est pas rare que mes fonctions reçoivent des auto_ptr<> quand elles sont des puits pour les données pointées reçues -- je préfère ça à une fonction qui prend un pointeur et qui signale dans un endroit obscur de la doc que la donnée pointée sera détruite. Dans le même genre, j'avais croisé un article qui présentait des pointeurs intelligents nondeletable<>. J'aime bien l'expréssivité rajoutée, même si tout devient plus verbeux.

Et il n'est pas rare non plus que je renvoie des auto_ptr<> pour mes fonctions qui agissent comme des sources de données. L'appellant sait immédiatement qu'il devra assumer la responsabilité de la donnée récupérée.

NB: Dans les cas sans déplacement, il y a les boost::scoped_ptr<> au détail qu'ils ne disposent pas de fonction release au contraire des auto_ptr<>. Du coup, il m'arrive d'écrire:

Code :

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

1
2
3
4
std::auto_ptr<T> t( new T(42) );
truc_qui_peut_lever_une_exception();
mon_vecteur.push_back(t.get()); 
t.release();

[ash.ice.loky]

Oui, il existe autant de SmartPointer que de cas de figure.

C'est a toi de voir ce qui te conviens le mieux.
Personnellement je deteste multiplier les possibilité, je prefere largement n'avoir qu'un SmartPointer et m'arranger pour qu'il marche a chaque fois sauf cas extreme.

Da cette optique j'ai fait ma propre classe de PointeurIntelligent, mais comme certain cas sont impossible.

* les tableaux [], donc on prend des vector (dans un sens c'est pas plus mal)
* les cycles (et la c'est trop gourmand a implementer)

A noter que c'est un excellent exercice.

[Matthieu Brucher]

C'est un excellent exercice, mais 99% des résultats de ces exercices ne seront pas à utiliser, les plus grands se sont plantés sur cet exercice périlleux !
Enfin, pour stocker des pointeurs dans un vector, le plus simple est de les encapsuler dans des shared_ptr<>