Discussion :

[Kromagg]

Bonjour

Je travaille sur un petit moteur de rendu, très simple, et je me demandais dans quelles situations utiliser les pointeurs brut plutôt que les pointeurs intelligent et inversement. Pour le moment j'utilise les pointeurs bruts en paramètre de fonction et en retour de fonction, et les pointeurs intelligent en interne dans les classes (renderer, resource manager...)

Avez-vous des suggestions ?

[Médinoc]

Utiliser des pointeurs intelligents avec sémantique de transfert (unique_ptr<>) en retour de fonctions qui allouent un objet. Cela permet d'en assurer la libération.

[Luc Hermitte]

Un bon résumé des cas d'utilisation de chacun: http://exceptionsafecode.com/slides/...shared_ptr.pdf

[moldavi]

Bonjour.

Personnellement je n'utilise plus les pointeurs intelligents. On peut largement s'en passer pour de petits programmes. Pour des usines à gaz pourquoi pas.

Il y a quelques techniques simples pour gérer les pointeurs bruts, même en environnement multithreadé. Pour les connaître, il suffit de jeter un oeil sur mon projet open source (cf signature).

Je préfère un pointeur brut qui me pète à la tronche pendant le débugage, plutôt qu'un pointeur intelligent qui me dit que tout va bien, je gère. C'est une perte de temps en moins. Et je peux t'assurer que mon problème principal à l'heure actuelle, ce n'est pas les pointeurs.

Les pointeurs intelligents vont peut-être libérés la mémoire, mais ils n'indiqueront pas toujours les erreurs de programmation. Ils peuvent même les masquer. De quoi s'arracher les cheveux.

J'ai fait mon choix : plus de pointeurs intelligents dans mes programmes. J'écris un petit peu plus de code (pas énorme), mais au moins je gère le déroulé de mon code avec précision.

[Luc Hermitte]

Il faudra m'expliquer en quoi unique_ptr (/auto_ptr en 98/03) sont une perte de temps.
Et côté erreur de programmation, c'est tout le contraire de ce que ton post suggère : ils indiquent clairement dans la signature des fonctions les responsabilités des appelants et appelés. Et mieux que ça, cela ne nous laisse pas le choix dans le code. C'est le même principe que les références qui indiquent qu'il n'y a pas à tester la non-nullité ou les constructeurs qui disent "si l'objet existe c'est qu'il est dans un état pertinent et utilisable".

[Luc Hermitte]

@jblecanard j'ai vu passer ton message mais tu l'as supprimé ^^
Je commence à abonder dans le même sens que toi au sujet des shared_ptr<>. C'est suite à la remarque de Sean Parent (comme quoi un shared_ptr<> n'est pas mieux qu'une globale) que je remarque que ma tendance passée à employer unique_ptr/auto_ptr était bonne et pas assez intensifiée. Et comme toi, je n'ai que très peu de ressources véritablement partagées (car aucun propriétaire ne peut être établi). C'est en bonne partie pour cela que j'ai donné un lien vers un pdf qui selon les cas d'utilisation propose un type qui sera plus adapté que les autres.

C'est sûr que shared_ptr<T*> ou T* paraissent plus simples à employer : on pose le cerveau là où on écrit ces types. Seulement, on doit deux fois plus gamberger au moment d'employer les choses qui les manipulent. Avec la gamme complète de types à notre disposition (ptr_vector<>, unique_ptr<>, références, et même T* et shared_ptr<>) on passe certes du temps à réfléchir à ce que l'on fait au début, mais à l'utilisation, on n'a plus à réfléchir. Le code devient statiquement blindé : les contrats (au sens PpC, oui) sont établis et ne peuvent pas être contournés sans le faire exprès.

Donc tout ça pour dire que oui, j'ai bondi en lisant que les pointeurs intelligents c'est le mal. Sauf que c'est mettre dans un même sac toute la gamme d'outils à notre disposition. Après qui sait, aujourd'hui j'attaque sans pudeur les singletons car se sont des globales, peut-être que dans quelques années je ferai la même chose avec les pointeurs intelligents à comptage de référence. En attendant aujourd'hui, je préfèrerai voir ce genre de types utilisés autour de moi (à commencer par les libs tierces) plutôt que de devoir appeler des fonctions de libération à la main.

[jblecanard]

Ha ben je remet mon message alors ! J'avais écrit en gros :

Je suis partiellement d'accord avec moldavi. J'uilise pour ma part des unique_ptr mais je fuis autant que possible les shared_ptr, qui devraient être utilisés avec parcimonie mais qui dans la pratique servent quand même pas mal à être paresseux et à mal concevoir la gestion de la propriété des objets. Leur usage pour transfert de propriété ne se justifie même pas avec la move semantics. Seul le cas de la propriété partagée est justifié et je ne l'ai dans la pratique jamais rencontré pour l'instant.

Je vais compléter avec un truc dont je n'avais pas parlé. Il y un use case que j'ai rencontré de nombreuses fois : c'est le cas d'un objet qui n'a qu'un seul propriétaire mais qui possède N observateurs, qui ont besoin de savoir si cet objet est encore existant ou non. Pour cela, on peut utiliser weak_ptr<>, mais de fait on est alors obligé d'utiliser shared_ptr<> pour le propriétaire. Soit un shared_ptr<> qui n'est pas et doit pas être partagé. C'est une utilisation acceptable pour ma part, mais ça serait bien d'avoir une sorte de couple uniq_ptr<>/weak_ptr<> qui couvre proprement ce cas.

[moldavi]

Bonjour Luc Hermitte.

J'ai utilisé les pointeurs intelligents pendant pas mal d'années. Maintenant que je fais des choses plus pointues, et que j'ai besoin de maîtriser le code de A à Z, les pointeurs intelligents me desservent et me font perdre du temps. C'est le constat après plusieurs années de service et j'en fais part. J'ai bien précisé que c'est mon choix. Je ne sais pas où tu as lu que les pointeurs intelligents, c'est le mal. J'ai même précisé que pour des usines à gaz, ça peut le faire.

Après, je retourne la question, il faudra m'expliquer en quoi unique_ptr (/auto_ptr en 98/03) sont un gain de temps. J'imagine que comme moi, tu n'auras pas le temps de me sortir une étude scientifique qui prouvera la chose. En conclusion cette attaque est plutôt mesquine.

On ne développe certainement pas le même type d'application. Je considère les pointeurs intelligents comme des outils. Outils qui ne répondent pas à toutes les exigences de programmation.

Evidemment cela concerne le type d'application que je développe. Et ce sont des applications hautes performances qui font intervenir le décodage audio/vidéo et de la 3d. Il y a une instruction non-stop chaque milliseconde. Ce n'est pas une application de gestion où l'utilisateur clique toutes les 10 secondes...

Donc voilà, une application temps-réel sans pointeur dans un environnement multithreadé, c'est possible.

Après chaque dévelopeur fait son choix. J'ai décidé de ne plus utiliser les pointeurs intelligents et je l'explique. Je ne dis pas aux développeurs de ne pas les utiliser. Je vois un développeur qui se pose des questions sur les pointeurs, je lui explique mon point de vue. Après il en fait ce qu'il veut. Pour moi un développeur ne doit pas suivre aveuglément des dogmes soit-disant universels. Il n'y a rien d'universel en informatique. Le développeur doit faire les choix adaptés à la situation. Connaître le plus de cas de figure possible, peut permettre de faire les meilleurs choix.

En ce qui concerne le comptage de référence, je considère que c'est le top du top pour la gestion de pointeur en environnement multithreadé. Il semble d'ailleurs que Microsoft soit fan aussi du comptage de référence. La discussion est ouverte.

PS: merci à jblecanard d'avoir remis son message. C'est fair-play.

[jo_link_noir]

Petit ou grand projet, je ne vois pas pourquoi l'utilisation d'un unique_ptr changerait.
Si le projet est petit on se permet d'avoir des ambiguïtés sur la responsabilité et trimbaler des pointeurs nus partout ? Je ne vois pas pourquoi.

J'ai zieuté ton projet @moldavi et j'ai surtout l'impression que tu bannis le Raii...
Gestion manuelle des fermetures (TRACE_CLOSE, unlock, ...) et je trouve la procédure de dés-allocation vraiment hideuse et sans intérêt comparé à un unique_ptr.
Comme c'est fort possible que je rate quelque chose, en quoi l'utilisation d'un pointeur intelligent te limite ?

Pour le shared_ptr, j'ai des exemples qui me semble pertinent (jeté moi des tagadas si je me trompe ):
- Une image qui peut être copier en ne prenant qu'une sous-partie. Plutôt que copier une zone de l'image on passe par un shared_ptr + un objet Rectangle.
- Un éditeur de code qui split les vue. Le fichier est ouvert en même temps que la première vue et fermer en même temps que la dernière vue.
- Tous se qui gère des données plus ou moins coûteuses en copie. Je pense à certaines implémentations de string et plus généralement les objets utilisant du cow. Mais là, c'est plus une question d'optimisation.

[jblecanard]

Salut

J'ai aussi été jeter un oeil au code. Ca me rappelle des souvenirs de code à la microsoft COM avec ces horribles AddRef();/Release(); qui empoisennent le code partout. Le comptage de référence peut être intéressant du moment que c'est abstrait correctement., et ne devrais pas être utilisé systématiquement avec tous les objets créés.

Il est évident que le peu de code qu'on lit n'est pas représentatif de la quantité de code écrite par Moldavi en plusieurs années. Juste sur le mfnode, ce que je remarque, c'est que juste pas du C++. Seul un subset de C++ assez limité est utilisé. Pour le reste, la logique est typique du C et de codeurs proches de la machine. Ce n'est pas en soit un mal de rester proche du C, mais c'est un choix assez engageant. As-tu aussi fait le choix de te passer de la STL complètement ? Ou c'est juste que "là tu n'en as pas besoin" ? C'est dommage de ne pas remplacer toutes ces macros par des constexpr.

S le C est un choix technique visant les hautes-performances, soit, mais du coup on parle plus du même langage. Moi à ta place quitte à me trimbaler un compilo C++ je m'en servirais à fond.

PS un peu hors sujet: Ca serait bien un mirroir github, c'est plus confortable pour lire le code

@jo_link_noir:

- Une image qui peut être copier en ne prenant qu'une sous-partie. Plutôt que copier une zone de l'image on passe par un shared_ptr + un objet Rectangle.
Oué mais attention au vieux piège ou l'on finit par converver des pointeurs qui utilisent de tout petits rectangle alors qu'en dessous la grosse image complexe reste en mémoire pour rien. Mais oui OpenCV utilise un peu ce genre de stratégie.
- Un éditeur de code qui split les vue. Le fichier est ouvert en même temps que la première vue et fermer en même temps que la dernière vue. Oui.
- Tous se qui gère des données plus ou moins coûteuses en copie. Je pense à certaines implémentations de string et plus généralement les objets utilisant du cow. Oui.

Exemple de problème des shared_ptr à grande échelle de code : un collègue d'une lointaine équipe a développé un menu dont vous n'avez que foutre et qui affiche une liste d'items que vous générez. Ce menu vous empêche de détruire convenablement vos objets car ils sont exposés via leur shared_ptr (pas le choix vous n'avez pas écrit le code originel). Une emmerde comme ça dans du code spaghetti et ça devient à se taper la tête contre les murs. Alors les shared_ptr dans les usines à gaz... sérieux mauvaise idée à moins de limiter la pratique et d'abuser des weak_ptr autant que possible, ça coûte pas plus cher que les shared.

[Luc Hermitte]

Hello

J'ai utilisé les pointeurs intelligents pendant pas mal d'années. Maintenant que je fais des choses plus pointues, et que j'ai besoin de maîtriser le code de A à Z, les pointeurs intelligents me desservent et me font perdre du temps. C'est le constat après plusieurs années de service et j'en fais part. J'ai bien précisé que c'est mon choix. Je ne sais pas où tu as lu que les pointeurs intelligents, c'est le mal. J'ai même précisé que pour des usines à gaz, ça peut le faire.

Après, je retourne la question, il faudra m'expliquer en quoi unique_ptr (/auto_ptr en 98/03) sont un gain de temps. J'imagine que comme moi, tu n'auras pas le temps de me sortir une étude scientifique qui prouvera la chose. En conclusion cette attaque est plutôt mesquine.

On ne développe certainement pas le même type d'application. Je considère les pointeurs intelligents comme des outils. Outils qui ne répondent pas à toutes les exigences de programmation.

Evidemment cela concerne le type d'application que je développe. Et ce sont des applications hautes performances qui font intervenir le décodage audio/vidéo et de la 3d. Il y a une instruction non-stop chaque milliseconde. Ce n'est pas une application de gestion où l'utilisateur clique toutes les 10 secondes...

Donc voilà, une application temps-réel sans pointeur dans un environnement multithreadé, c'est possible.

Après chaque dévelopeur fait son choix. J'ai décidé de ne plus utiliser les pointeurs intelligents et je l'explique. Je ne dis pas aux développeurs de ne pas les utiliser. Je vois un développeur qui se pose des questions sur les pointeurs, je lui explique mon point de vue. Après il en fait ce qu'il veut. Pour moi un développeur ne doit pas suivre aveuglément des dogmes soit-disant universels. Il n'y a rien d'universel en informatique. Le développeur doit faire les choix adaptés à la situation. Connaître le plus de cas de figure possible, peut permettre de faire les meilleurs choix.

En ce qui concerne le comptage de référence, je considère que c'est le top du top pour la gestion de pointeur en environnement multithreadé. Il semble d'ailleurs que Microsoft soit fan aussi du comptage de référence. La discussion est ouverte.

Ils sont un gain de temps à l'utilisation quand il n'y a plus besoin de suivre tous les chemins de code pour collecter les ressources. Ils sont un gain de temps à la maintenance quand six mois plus tard on reprend un morceau de code et là il faut repartir dans la doc d'une fonction car sa signature ne permet pas de savoir ce qu'elle fait du pointeur qu'elle reçoit. Et encore, ça c'est quand la doc est correctement écrite. Souvent, c'est le code qu'il faut aller regarder.
Et là, je ne parle que des unique_ptr/auto_ptr qui introduisent une sémantique de déplacement de responsabilité dans les signatures des fonctions. Pas des shared_ptr, qui je le conçois, ont un prix en terme de design et d'exécution.
Je le redis, ils sont dans la même catégorie de gain de temps que les références, que les constructeurs vs les fonctions init(), et je rajouterai même que langage compilé Vs langage interprété (mais certains diront le contraire).

Tout à fait, ce sont des outils. Des outils dans le sens d'un code robuste et maintenable. Je connais parfaitement les codes sans RAII. C'est juste inmaintenable et avec des fuites toutes les dix fonctions. Et si par malheur il y a des exceptions au milieu (même dans des codes à la C si jamais il y a des new ou n'importe quoi de la SL) là, c'est le drame.


Mon secteur ? Les systèmes critiques. En multithréadé et/ou embarqué. C'est sûr, ce ne sont pas des toys projects que l'on écrit pour répondre à un exercice dans un forum ou pour tester des fonctionnalités du langage. Des usines à gaz ? Hum. A partir de quand un code, ou même une lib est une usine à gaz ? Perso, à la deuxième ressource allouée, je range de suite dans la catégorie "Je veux du RAII pour surveiller les ressources, je ne veux pas surveiller les chemins". Sans le RAII, à la deuxième ressource, on est déjà dans le pays des usines à gaz.

Quelqu'un que je respecte énormément, racontait régulièrement sur USENET que les GC ont de gros avantages dans des applis MT.

[moldavi]

Bonjour.

Je ne sais pas comment fonctionne la récupération de message sous developpez.net, mais si un modérateur pouvait remettre mon dernier message ce serait sympa. J'espère que le cache de mon message est sur votre serveur, sinon indiquer-moi où il se trouve sur mon ordi, merci.

[germinolegrand]

@moldavi: j'en suis navré, mais il a dû se perdre. (j'extrapole probablement mais la récupération de message doit se faire à partir d'une session PHP ou d'un cookie, ce qui limite quelque peu les possibilités, j'en ai moi-même fait les frais il y a quelques temps).

Pour ma part depuis maintenant 2 ans que je ne fais plus que de ça, j'en suis à la position suivante si je caricature : les unique_ptr c'est la vie, les shared_ptr c'est la mort, les pointeurs nus c'est des pointeurs nus c'est à dire ce qu'on peut trouver de plus bas niveau (presque, y'a les void* en dessous ).

Pour détailler un peu plus parce que je n'apporte rien de plus sinon, les unique_ptr apportent une tranquillité d'esprit assez agréable, puisqu'une utilisation régulière et maitrisée assure de n'avoir aucun segfault dû à des problèmes de mémoire. Honnêtement. Les seuls bugs qui restent sont des bugs d'algorithmie. (et donc de fonctionnalités, ce qui nous rapproche fichtrement d'une programmation haut-niveau).

Le tout en rendant le code plus lisible et plus cohérent, c'est le nec-plus-ultra.

Pour les shared_ptr maintenant, je ne les rangerais pas dans la même case qu'une globale, parce que je ne lui reproche pas les mêmes griefs. Une preuve de leur mauvaise utilisation (parce que cela reste un outil, il ne peut donc pas être mauvais en soi) se trouve dans la STL elle-même : weak_ptr. Lorsqu'on en vient à mettre un weak_ptr, on avoue explicitement avoir un scope (faut vraiment qu'on trouve un terme français pour ça) complètement non maîtrisé : on ne sait pas si l'objet est créé ou détruit ou ?? alors qu'on en est simplement l'utilisateur et non le responsable. Dans un grand nombre de tous les cas que j'ai croisés, ça a mené direct à un gros problème de conception (je déteste cet argument du problème de conception, c'est vraiment trop vague et subjectif) un problème d'ordre de destruction (en d'autres termes : un problème pour l'OLTC qui m'est cher ).

Pour les shared_ptr eux-mêmes, eh bien... Je dirais que leur véritable utilité se trouve dans tout ce qui ne faisait pas partie du concept initial, c'est à dire l'atomicité des opérations.

Mais c'est que std::shared_ptr en fait trop, l'implémentation intrusive (nécessairement ? à creuser) de weak_ptr dans shared_ptr le montre encore une fois, c'est un agglomérat de fonctionnalités pour un utilitaire qui se veut haut-niveau, mais vous me le pardonnerez c'est du haut-niveau Java/C# insolite dans un code C++, ça ne peut que difficilement se traduire en haut-niveau C++ (qui de ce que j'en expérimente se veut déterministe, sécurisé, optimisé, expressif, non-intrusif et surtout réversible à volonté).

Pour les pointeurs nus maintenant... eh bien je dirais que l'utilité est extrêmement limitée quand on ne trafique pas des pools mémoire et des buffers (et encore, même std::vector pourrait s'en tirer mieux que vous à ce niveau là).
Je dirais qu'ils servent très essentiellement à implémenter des pointeurs intelligents (et je ne voudrais surtout pas qu'ils disparaissent du langage, toujours dans cette optique du réversible à souhait).

Pour les pointeurs en général maintenant : je vais me ranger du côté de Stroustrup, et prôner leur non exposition dans une interface publique d'un module.

[gl]

Germinolegrand, j'ai l'impression que l'on fait le même constat a propos des shared_ptr sans en tirer la même conclusion ni le même défaut. Effectivement ils sont sur utilisé et bien souvent a mauvais escient mais je n'y vois pas un problème intrinsèque juste une mauvaise utilisation et probablement une mauvaise compréhension. Un shared_ptr c'est une responsabilité partagée (et il est très bien pour ça), et non une responsabilité vague et non définie mais il est malheureusement souvent utilisé dans ce rôle.

En fait c'est le même type de reproche que celui régulièrement fait au GC.

Concernant weak_ptr, ce n'est pas de mon point de vue une erreur mais juste un mécanisme permettant d'avoir un observateur non possédant. Honnêtement, l'absence d'un mécanisme similaire sur les unique_ptr me manque. Là encore, le problème ne me semble pas être weak_ptr lui même mais l'usage qui en est trop souvent fait.

[Iradrille]

En fait c'est le même type de reproche que celui régulièrement fait au GC.

En mettant de coté l'impact sur les performances d'un GC (peut provoquer des freezes non prévisibles, qui peuvent gêner dans les applis temps réels : jeux par exemple), c'est le 2eme gros défaut : il n'y a pas de réelle notion de possession d'objet, ça revient à utiliser des shared_ptr partout.

Concernant weak_ptr, ce n'est pas de mon point de vue une erreur mais juste un mécanisme permettant d'avoir un observateur non possédant. Honnêtement, l'absence d'un mécanisme similaire sur les unique_ptr me manque. Là encore, le problème ne me semble pas être weak_ptr lui même mais l'usage qui en est trop souvent fait.

Pour moi le couple shared_ptr/weak_ptr est similaire au couple unique_ptr/pointeur nu. (Ou unique_ptr/ref).

Si on sait que la ressource existe, on peut garder un pointeur nu sur la ressource.
Sinon, on peut redemander un pointeur sur la ressource à l'objet gérant la ressource.

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
class Resource { };
class ResourceHolder {
    std::unique_ptr<Resource> res;
public:
    Resource *get() const { return res.get(); }
};
 
// à l'utilisation
resourceHolder rh;
auto ptr = rh.get();
// plus tard, si aucun doute sur la validité de la resource :
ptr-> ... ;
// sinon
ptr = rh.get();
if(ptr) {
   ptr-> ... ;
}

Un système similaire aux weak_ptr supprimerait le besoin de garder une référence sur le "ResourceHolder", mais n'est pas non plus quelques chose d'essentiel.

(par contre un gros problème est l'absence de make_unique avec C++11).

[gl]

En mettant de coté l'impact sur les performances d'un GC (peut provoquer des freezes non prévisibles, qui peuvent gêner dans les applis temps réels : jeux par exemple), c'est le 2eme gros défaut : il n'y a pas de réelle notion de possession d'objet, ça revient à utiliser des shared_ptr partout.

Juste une petite remarque sur les performances d'un GC : c'est très dépendant de la techno du GC, du système d'exploitation et des cas d'utilisation. D'un côté tu risques les latences dont tu parles mais aussk une consommation mémoire plus importante en moyenne, mais de l'autre tu peux avoir une plus faible fragmentation mémoire (effet du compactage) ou de meilleures performances grâce au recyclage mémoire et a l'allocation par zone (ce qui peut s'obtenir avec un pool également).

Sinon, c'est bien ce point dont je parlais : on a vendu les GC avec l'argument de ne plus avoir à gérer la mémoire, du coup fort logiquement il y a un courant de rejet des GC à cause de ce point et la perte de responsabilité.
Alors que le GC n'est qu'un outil permettant de mettre en place une politique particulière de gestion mémoire avec ces caractéristiques propres mais ne dispense pas de réfléchir à ladite gestion ni a la responsabilité des allocations.

Pour moi le couple shared_ptr/weak_ptr est similaire au couple unique_ptr/pointeur nu. (Ou unique_ptr/ref).

Sur un plan purement technique, je suis d'accord. Mais le souci est le manque de sémantique du pointdur nu : ai-je la responsabilité de ce qui est pointé ? De manière exclusive ou partagée ? Quoi appeler pour libérer ? C'est ce point qu'ameliorerait un weak_ptr pour unique_ptr.

(par contre un gros problème est l'absence de make_unique avec C++11).

Tout a fait

[Iradrille]

Sur un plan purement technique, je suis d'accord. Mais le souci est le manque de sémantique du pointdur nu : ai-je la responsabilité de ce qui est pointé ? De manière exclusive ou partagée ? Quoi appeler pour libérer ? C'est ce point qu'ameliorerait un weak_ptr pour unique_ptr.

Dans une appli utilisant des smart pointers, un pointeur nu serait comme un weak_ptr : aucune responsabilité sur la ressource pointée.
Dans la pratique, toutes les bibliothèques ne respectent pas ça, en particulier les lib C (et oui, pas d'unique_ptr en C).

Mais si les ressources allouées via une bibliothèque utilisant des pointeurs nus sont correctement encapsulées, on peut garder cette sémantique de pointeur nu = aucune responsabilité.
C'est du boulot supplémentaire par rapport à un type "weak_unique_ptr" par contre, c'est vrai.

[Jean-Marc.Bourguet]

Pour détailler un peu plus parce que je n'apporte rien de plus sinon, les unique_ptr apportent une tranquillité d'esprit assez agréable, puisqu'une utilisation régulière et maitrisée assure de n'avoir aucun segfault dû à des problèmes de mémoire.

Les segfaults sont souvent dû à des pointeurs qui auraient dus être modifiés (donc, pour les éviter, il faudrait des weak pour les unique_ptr + tester à chaque utilisation alors que logiquement ils ne devraient pas être nuls).

En fait c'est le même type de reproche que celui régulièrement fait au GC.

Le comptage de références est un algo de GC, avec des avantages (synchrone par exemple) et des inconvénients (ne traite pas cycles par exemple) par rapport aux autres algo de GC.

[Neckara]

Bonjour,

Je vois que vous parlez de "weak_unique_ptr".
Or, pour moi, std::unique_ptr dit "je possède l'unique référence de l'instance", "je suis le seul à pouvoir accéder à cette instance".
Ce qui permet de se passer de certaines vérifications de mutex, etc. dans certains contextes.
Ainsi un "weak_unique_ptr" serait pour moi incohérent.

Je pense qu'utiliser un seul shared_ptr avec des weak_ptr serait plus cohérent qu'un "weak_unique_ptr".
Après deux cas :

• on ne veut qu'un seul shared_ptr vers l'instance :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
class Foo
{
     public :
       Foo(std::unique_ptr)
          : m_ptr(toto)
 
      std::weak_ptr ptr() { return m_ptr->jeSaisPlus(); }
 
      private : 
          std::shared_ptr m_ptr;
}

• on tolère plusieurs shared_ptr

Après si on veut que l'unique "shared_ptr" se balade très régulièrement, cela risque de poser un problème :

• on prend en entrée un unique_ptr : on demande donc explicitement l'unique référence mais on va mettre à nullptr les weak_ptr déjà existant ;
• on prend en entrée une référence vers un shared_ptr : on a pas la garantie que le shared_ptr passé en paramètre était bien l'unique shared_ptr existant ;

Dans ce cas là, je pense que le mieux reste d'hériter de shared_ptr puis d'interdire l'opérateur d'affectation et de redéfinir/définir une méthode move() (?)

[Iradrille]

Bonjour,

Je vois que vous parlez de "weak_unique_ptr".
Or, pour moi, std::unique_ptr dit "je possède l'unique référence de l'instance", "je suis le seul à pouvoir accéder à cette instance".

Dans cette optique des "weak_unique_ptr", ou même un pointeur nu sur la ressource n'a pas de sens.

Mais j'ai une autre vision (peut être mauvaise) des unique_ptr : "je possède la ressource, je gère sa durée de vie, si tu veux l'utiliser je te donne un pointeur nu, mais la delete pas". Et dans cette optique des "weak_unique_ptr" pourraient remplacer les pointeurs nus (pour pouvoir vérifier la validité de la ressource et lever l’ambiguïté sur les pointeurs nus).