Discussion :

[FunkyTech]

Bonjour à tous.

Intitulé explicite, n'est-ce pas ? ^^
Donc voila peut-on utiliser les shared_ptr de boost sans ce privé ou faut-il seulement les utiliser quand c'est nécessaire ?

Merci d'avance

[Sylvain Togni]

Je dirais que comme toute technique, il ne faut l'utiliser que quand c'est nécessaire, c-à-d quand elle apporte quelque chose par rapport aux autres alternatives.

Typiquement les shared_ptr s'utilisent, comme leur nom l'indique, pour gérer la durée de vie d'objets partagés. Mais il arrive qu'ils puissent servir dans d'autres contextes, par manque d'alternatives (auto_ptr a une sémantique bien spéciale), comme par exemple pour stocker des objets polymorphes dans des conteneurs.

[Médinoc]

Si tu veux utiliser ce genre de pointeurs intelligents "sans te priver", je te conseillerais plutôt de le faire de manière intrusive: mettre un compteur de références dans tes objets et utiliser des intrusive_ptr<>...

[Centabarnak]

Sachant que par définitions les shared_ptr sont des objets, leur utilisation rend ton programme plus lourd. Mais sur un sytème qui se respecte, ce type de contrainte, de nos jours, ne pose plus de problèmes.

Il est préférable d'utiliser des shared_ptr que de se retrouver avec des espaces mémoires non désalloués par exemple.

[loufoque]

Personnellement je n'ai jamais trouvé l'intérêt de shared_ptr.
Si je veux partager la propriété d'une donnée, j'utilise plutôt une flyweight factory (qui résout un certain nombre des problèmes de shared_ptr par ailleurs)

[Médinoc]

Peux-tu donner des détails sur ce qu'est une flyweight factory ?

[Davidbrcz]

A tout hasard je dirais une composition entre 2 design pattern.
Celui ci et celui là

[Klaim]

J'ai essayé sans et avec uniquement des shared_ptr il y a quelques années, pour la même (grosse) application (un jeu vidéo).

Ma conclusion est aussi qu'il ne faut l'utiliser qu'au moment ou on en sent le besoin.
Au final il n'y a que dans un type de cas ou l'utilisation me semble la plus naturelle : pour les objets représentant des ressources potentiellement partagées par plusieurs système et qui ne sont pas "managés" au sens ou il n'y a pas un manager déjà présent qui "détient" ces resources et les détruira sur commande. L'utilisation d'un manager de cette manière m'est bien plus courante que l'utilisation du shared_ptr à vrai dire.

[loufoque]

Au final il n'y a que dans un type de cas ou l'utilisation me semble la plus naturelle : pour les objets représentant des ressources potentiellement partagées par plusieurs système et qui ne sont pas "managés" au sens ou il n'y a pas un manager déjà présent qui "détient" ces resources et les détruira sur commande. L'utilisation d'un manager de cette manière m'est bien plus courante que l'utilisation du shared_ptr à vrai dire.

Chose pour laquelle tu ferais mieux d'utiliser par exemple Boost.Flyweight.

[Klaim]

Oui mais au final non : j'ai quasiment jamais d'instances similaires... Mais je suis au courant de l'existence de la lib et je compte l'essayer dés que j'ai un cas évident (ou peut être en phase d'optimisation)

[Feriaman]

Salut,

Si je veux partager la propriété d'une donnée, j'utilise plutôt une flyweight factory (qui résout un certain nombre des problèmes de shared_ptr par ailleurs)

Chose pour laquelle tu ferais mieux d'utiliser par exemple Boost.Flyweight.

Merci de m'avoir fait découvrir Boost.Flyweight.
La Factory en question me rappelle pas mal la mutualisation des chaines de caractère en Java.

Je m'interroge sur la différence entre ceci et un manager. Dans les deux cas tu donne la responsabilité de l'ensemble de tes objets à un seul objet extérieur qui les gère pour toi. Probablement dans les deux cas, l'objet en question les mutualise...

Je rappelle que Herb Sutter et Andrei Alexandrescu ont une opinion très tranchée sur le sujet des shared_ptr

Quand à moi, je crois qu'il faut que les objets qui sont responsable de la libération des pointeurs soient des objets dédiés. Pas forcément des shared_ptr ou des managers/mutualiseurs, mais des objets dédiés.

Toutefois, je n'ai pas beaucoup d'exemple pour lesquels ni les shared_ptr, ni un manager/mutualiseur ne conviennent.

Un seul exemple me vient : j'ai eu à coder il y a quelques années un serveur qui pouvait recevoir des message de :
- plusieurs threads sur la même machines
- plusieurs threads sur d'autres machines
Tous devaient tous être traités de la même manière, et les messages étaient de types variés mais statiques.
J'ai choisi que les threads d'une même machine communiqueraient entre eux en se passant des pointeurs d'objets "message", et j'ai du mettre en place pour cela un mécanisme d'allocation/libération de ressource pour ces messages qui était intimement lié à la couche de communication :
Les messages ne pouvaient être créés que par un objet unique (par machine) de création de message et pouvaient être détruit :
- soit par le thread qui envoie le message à une autre machine (sur les machines clients), après avoir vérifié qu'il avait été traité par le serveur.
- soit par le thread serveur qui traite les message (sur la machine serveur)

La particularité de ceci par rapport à un manager, c'est qu'à un instant donné, un message ne pouvait être accédé que par un unique thread.

Bonne journée

[loufoque]

Je m'interroge sur la différence entre ceci et un manager.

C'est la même chose, sauf que celui-ci est implicite et est réalisé automatiquement.

Je rappelle que Herb Sutter et Andrei Alexandrescu ont une opinion très tranchée sur le sujet des shared_ptr

Ils disent quoi exactement ?
(Non pas que ce soient de si bonnes références, je pense sérieusement qu'on en dit trop à leur sujet)

Y'a plein d'exemples d'utilisation, sinon.
Par exemple tous les cas où tu ne veux charger une ressource nommée qu'une fois, pour éviter de recharger un truc qui est déjà chargé ailleurs dans le programme. Par exemple des polices, des sprites, des meshs, que sais-je.

[Matthieu Brucher]

Sachant que par définitions les shared_ptr sont des objets, leur utilisation rend ton programme plus lourd. Mais sur un sytème qui se respecte, ce type de contrainte, de nos jours, ne pose plus de problèmes.

Plus lourd ?? Au contraire, c'est plus simple et plus clair !

[Médinoc]

Peut-être voulait-il dire "en terme de performances"...

[Matthieu Brucher]

Pas certain qu'il y ait un véritable impact au niveau performances.

[Aurelien.Regat-Barrel]

Sur de tous petits objets alloues en grand nombre, ca risque de devenir visible parce que shared_ptr doit allouer et gerer la memoire pour stocker et associer les compteurs avec chaque instance (Medinoc a donne une alternative).

Mais pour quelque chose d'aussi serieux que la gestion de la memoire, se priver des shared_ptr pour cette hypothetique raison, c'est a mon sens pas suffisant.