Gestion de pointeur

Hello,

Disons que vous avez une fabrique qui doit instancier un objet.
Le pointeur renvoyé va avoir plusieurs utilisateurs.

L'appelant de la fabrique devra gérer la durée de vie du pointeur, et tous les autres utilisateurs de ce pointeur auront toujours une durée de vie plus courte.

Quel type de pointeur utilisez-vous ?

J'aurais tendance à ce que la fabrique renvoie un unique_ptr, qui sera détenu par l'appelant, et que les autres utilisateurs y aient simplement accès par un pointeur brut. Mais rien n'empêcherait ces derniers de faire un delete dessus...

La shared_ptr ma chagrine, car la gestion de la durée de vie est partagée, ce qui ne correspond pas au cas d'utilisation.

Le weak_ptr impose de créer un shared_ptr à chaque utilisation.

Que faites-vous, dans ce cas là ?

L'objectif est d'utiliser les types des entrées et sorties de chaque fonction pour expliciter qui est propriétaire et manager d'une ressource.

Définissons dans un premier temps :

Code:

---

1 2	// Une ressource devant être managée struct Object {};

---

Nous parlons ensuite d'une factory :

Code:

---

1 2	// Une Factory à Object. Puisqu'elle retourne un unique_ptr, elle explicite que l'appelant est propriétaire de la mémoire qu'elle alloue. std::unique_ptr<Object> factory() { return std::make_unique<Object>(); }

---

(ne pas oublier d'#include <memory>)

Son appelant est donc :

Code:

---

1 2 3 4 5 6

// Un manager d'Object. En appelant factory(), il se désigne comme propriétaire de la mémoire et manager de la ressource. void owner() { auto object = factory(); user(*object); }

---

Ici, en ignorant tous les commentaires, un lecteur comprendra simplement par les types en question qui manage quoi :

• factory alloue mais laisse à l'appelant le soin de libérer la mémoire, bien que tout soit automatiquement fait par RAII (std::unique_ptr) ;
• owner en tant qu'appelant manage la ressource et laisse user y accéder soit par valeur, soit par référence, soit par référence constante ;
• user n'est clairement pas propriétaire ou manager de la mémoire d'object.

On peut donc par exemple définir

Code:

---

1 2	// Une utilisation non propriétaire d'un Object. Puisque cette fonction prend une référence (const ?), il est explicite qu'elle ne peut pas être manager de cette ressource. void user(const Object&) {}

---

Code complet et démo en live sur coliru.

En faisant fi de l'intérêt d'avoir un pointeur sur un entier (imaginons plutôt un pointeur vers une classe de base d'une hiérarchie), le code suivant serait-il le modèle à suivre ?

Code:

---

1 2 3 4 5 6 7 8 9

class Foo { public: Init() {...} // initialise toto const int& GetToto() { return *toto; } private: std::unique_ptr<int> toto; };

---

Pourquoi pas unique_ptr interne à l'appelant qui offre un accès à l'objet par référence ? Si retourner un pointeur te fait peur (ce qui ne devrait pas être le cas).
Et si tu me sors le "risque que quelqu'un fasse un delete &ref;" sur la référence : autant ne rien faire, y'a pas de solution si les utilisateurs font juste absolument n'importe quoi.

edit: oui exactement ton code ci-dessus

OK, vendu.

Merci à tous !

Salut,

Ceci dit, il n'y a a priori aucune raison pour que ce soit la fabrique qui soit propriétaire de la ressource qu'elle crée: le role de la fabrique, c'est de créer la ressource, point-barre. Si tu commences à donner plus de responsabilités à la fabrique, tu ne vas pas tarder à la nommer manager, et, comme c'est un terme qui ne veut rien dire tellement il a de significations, tu finiras rapidement avec une classe monolithique que tu auras peur de regarder de trop près, et plus peur encore d'essayer de modifier.

L'idéal est donc au moins de séparer ce qui construit de tes ressources de ce qui les maintient en mémoire ;)

Après, l'idéal est toujours de garder un propriétaire unique et clairement identifié pour tes ressources. Tu le dis d'ailleurs toi-même: tu as plusieurs utilisateurs, mais tu veux que ta fabrique soit la seule à en gérer la durée de vie.

Si on prend la remarque que je viens de faire en compte, on ne fait que transposer le fait que c'est ce qui maintient les ressources en mémoire qui s'occupe de gérer leur durée de vie ;)

Et, dans ce cas, l'utilisation d'un std::unique_ptr est totalement justifiée. Libre à toi de décider de permettre aux utilisateurs des ressources d'y accéder sous forme de référence (ce qui sera toujours préférable) ou sous forme de pointeur nu, en faisant bien attention au fait que la présence d'un pointeur nu est alors synonyme de non propriété ;)