shared_ptr bon usage

Bonjour,

soit un vector<Obj>

si je souhaite avoir un pointeur sur une entrée de ce vector puis-je utiliser un shared_ptr ?

J'ai un peu peur que le destructeur d'un des objets pointés soit appelé dés lors que le shared_ptr est détruit sauf que je ne souhaite pas que le vector initial soit modifié lors de la suppression du shared_ptr..

Une solution ou un "best practice" dans ce cas précis ?

Merci.

2eme question :

pour initialiser le pointeur vous feriez comme ça :

Code:

---

1 2 3

vector<Obj> v; boost::shared_ptr<Obj> p = boost::shared_ptr<Obj>( &v[0] );

---

Citation:

---

si je souhaite avoir un pointeur sur une entrée de ce vector puis-je utiliser un shared_ptr ?

---

Euh... Pourquoi tu voudrais un pointeur sur un vector ? C'est pour partager ce vecteur entre plusieurs objets?
Si la réponse est oui, alors oui tu peux ! ;)
Si t'as pas besoin de ce partage, alors tu ne veux pas de pointeurs...

Citation:

---

J'ai un peu peur que le destructeur d'un des objets pointés soit appelé dés lors que le shared_ptr est détruit sauf que je ne souhaite pas que le vector initial soit modifié lors de la suppression du shared_ptr..

---

Oulà, tu n'as pas compris comment fonctionne shared_ptr. Si shared_ptr est détruit, c'est que tu sors de la portée de l'existence de ta donnée. Et donc shared_ptr ou pas, tu n'as plus accès à ta donnée.

Citation:

---

pour initialiser le pointeur vous feriez comme ça :

Code:

---

1 2 3

vector<Obj> v; boost::shared_ptr<Obj> p = boost::shared_ptr<Obj>( &v[0] );

---

---

Surtout pas ! Tu vas mettre deux responsabilités sur le même objet. vector détruit ses éléments quand il est détruit, et shared_ptr aussi... :aie:

Code:

---

boost::shared_ptr<vector<Obj> > p (new vector<Obj>(...));

---

Salut
Comme le dit poukill, std::vector gère déjà le pointeur du tableau dynamique. Tu n'as pas à t'en occuper. Et pour récupérer un élément, ben autant prendre par référence (au besoin constante). Pourquoi vouloir un pointeur ?

Salut,

A l'extrême (mais vraiment extrême) limite, si tu veux récupérer un pointeur sur ton objet pour le passer, par exemple, à une fonction C, tu peux toujours envisager de passer... l'adresse de l'élément en question, sous une forme proche de

Code:

---

1 2 3

void fonctionC(&monvecteur[5]); /* ou de */ void fonctionC(&monveteur[0], monvecteur.size()); //fonction qui demande un tableau C style

---

mais il faut savoir (et tenir compte du fait) que toute modification du vecteur (ajout ou suppression d'éléments) risque d'invalider le pointeur ;)

[EDIT] Et, bien sur, il faut veiller à ce que la fonction C ne fasse pas de conneries avec le pointeur reçu (telles que tenter une réallocation de la mémoire) :aie:

pourquoi un pointeur, j'aimerais le design suivant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class Foo { ListeObjClass liste; Obj * ptrSurUnObjet; // = &vec[i] }   class ListeObjClass { vector<Obj> vec; };

---

Dans ce cas là il convient d'utiliser un pointeur brut et non "smart" ?

Ben t'as pas besoin de shared_ptr pour ça...
ptrSurUnObjet n'alloue pas de mémoire, n'en libère pas. Il pointe juste sur un élément de ton conteneur...

Comme dit poukill, un simple pointeur ou une reference sur l'objet suffise ici. Toutefois, ce genre de chose est extrèmement fragile, et donc probablement à éviter. Si ton vector vient à être réallouer, toutes tes références, pointeurs et autres itérateurs sont invalidés, et tu te retrouve à pointer sur des choses plus qu'aléatoire.

Pourquoi as-tu "besoin" de faire ça ?

Citation:

---

Envoyé par zul

Comme dit poukill, un simple pointeur ou une reference sur l'objet suffise ici. Toutefois, ce genre de chose est extrèmement fragile, et donc probablement à éviter. Si ton vector vient à être réallouer, toutes tes références, pointeurs et autres itérateurs sont invalidés, et tu te retrouve à pointer sur des choses plus qu'aléatoire.

Pourquoi as-tu "besoin" de faire ça ?

---

Oui finalement je peux stocker ça par valeur, et non via un pointeur.
donc au final on peut encore trouver des cas ou l'emploie d'un pointeur brut se justifie, j'étais partis avec l'idée que dorénavent shared_ptr and co devait être utiliser systématiquement

Citation:

---

Envoyé par guillaume07

donc au final on peut encore trouver des cas ou l'emploie d'un pointeur brut se justifie, j'étais partis avec l'idée que dorénavent shared_ptr and co devait être utiliser systématiquement

---

Personne n'a jamais dit ça. On dit que pour la gestion des ressources, l'idiome RAII doit être utilisé pour faire les choses proprement.
Dans ce cadre, l'allocation mémoire brute (via new) doit être passée directement à une classe qui en prend la responsabilité. shared_ptr est un client particulièrement adapté pour ce genre de situation, en général. Il s'occupe de la ressource, permet de la partager via un compteur, et la libère à la fin.
Quand un débutant dit création de "pointeur", il pense allocation de mémoire. Les experts répondent : "Attention à ne pas laisser se balader ta ressource par pointeur nus. Tu risques : fuite de mémoire, double delete, par exemple. Pour aller plus vite, on répond : "shared_ptr". ;)
Dans ton cas précis ici, ton pointeur est juste là pour pointer. Il ne fait rien d'autre. Au pire, il pointe n'importe où si tu l'as mal géré... Mais ce n'est pas lui qui gère une ressource. Il n'a aucune responsabilité !

Autre cas, std::vector est un cas de demande de nouvelle ressource entièrement gérée par la classe elle-même. Elle est exception-safe, donc tu peux t'appuyer dessus sans problème. Elle n'a pas besoin de shared_ptr, et s'occupe de libérer ses éléments automatiquement. Si vector contient des pointeurs, alors il vaut mieux utiliser ptr_vector, ou bien std::vector<shared_ptr> si on veut partager ses éléments.

En résumé, la gestion de la mémoire en C++ se résume à : "A qui je donne la responsabilité de la gestion de cette ressource?".
- std::vector libère ses éléments. S'il contient des pointeurs, il efface bêtement ces pointeurs sans appeler delete.
- pr_vector est responsable de ses pointeurs: il appelle delete
- shared_ptr est responsable de son pointeur
- weak_ptr ne l'est pas, mais offre un mécanisme de vérification d'existence de la ressource
- std::vector<shared_ptr<obj>> va détruire ses éléments quand il est lui même détruit. La destruction du shared_ptr va entrainer la libération de la mémoire s'il était le seul à pointer dessus...
etc....

Citation:

---

Envoyé par poukill

- std::vector<shared_ptr<obj>> va détruire ses éléments quand il est lui même détruit. La destruction du shared_ptr va entrainer la libération de la mémoire s'il était le seul à pointer dessus...
etc....

---

quand tu dis le seul à pointer dessus, c'est finalement si le constructeur par recopie ou bien l'opérateur d'affectation du shared_ptr n'a pas été appelé ? c'est dans ces deux seuls cas ou le compteur est incrémenté ?


une fonction comme void f(shared_ptr<Obj>& p) ne provoque pas l'incrémentation du pointeur ? le partage à bien lieu uniquement via copie ou affectation ?

merci

Tout à fait.
Le passage par référence n'incrémente pas le compteur.
Le constructeur par copie oui, et l'operator= aussi.