Discussion :

[nonozor]

Bonjour,

j'ai des objets de type A dont un attribut est un pointeur vers un objet de type B. Cet objet de type B n'existe que pour être utilisé par un objet de type A et doit donc être supprimé lorsque l'objet qui l'utilise est supprimé.
Cependant, plusieurs objets de type A peuvent avoir leur attribut pointant vers le même objet de type B. Il ne faut donc pas que le destructeur de A supprime l'objet B pointé par l'attribut. Mais alors, quand tous les objets A seront supprimés, l'objet B sera toujours dans la mémoire alors qu'il devrait être supprimé.

Est ce que transformer l'attribut de A en shared pointer vers un objet B est la bonne solution à mon problème?

Est ce que je peux créer de nombreux shared pointers sans trop affecter mes ressources mémoires et temps CPU?

Merci d'avance!!!

[3DArchi]

Salut,
As-tu lus les 2 tutoriels suivant : Présentation des pointeurs intelligents en C++, par Loïc Joly et Boost.SmartPtr : Les pointeurs intelligents de Boost par Matthieu Brucher ?

De ce que tu décris, effectivement, les shared pointeur t'apportent une solution à ton problème.
Quand aux problèmes de perfs : en gros tu rajoutes un compteur de référence sur ton pointeur partagé et éventuellement une indirection supplémentaire s'il n'y a pas d'inlining. Si tu es sur PC, prouve-moi que cela a un impact mesurable sur tes perfs

[poukill]

+1.
La perte en perf est tellement minime que tu la verras pas. En plus, vu le gain avec les shared_ptr au niveau "safety", ce serait une hérésie que de ne pas les utiliser dans ton cas.

D'ailleurs, comment faire autrement ?

[nonozor]

Merci de vos réponses! Je vais utiliser les shared_ptr!!!

D'autre part, en y réflechissant, il y a peu de cas où les shared_ptr ne sont pas utiles par rapport aux pointeurs "nus".

Est ce qu'il y a des cas où vous utilisez des pointeurs nus plutot que des shared_ptr? Pour un "void func( const type * ptr )" ou un "const type * getter()", par exemple?

[Goten]

Non pour ce genre de chose j'utilise des références...

[nonozor]

citation de boost.org

A simple guideline that nearly eliminates the possibility of memory leaks is: always use a named smart pointer variable to hold the result of new. Every occurence of the new keyword in the code should have the form:

shared_ptr<T> p(new Y);

Si tout le monde faisait cela, on ne verrai jamais aucun "pointeur nu", non?
Qu'est ce que vous en pensez?
Il y a des cas où il vaut mieux utiliser des pointeurs nus???

[Goten]

non

[poukill]

Dans mes 100 000 lignes de code de mon projet, les seuls pointeurs nus que je manipule sont ceux de Qt, parce que c'est une bibliothèque qui s'occupe elle même de la libération de la mémoire de ses propres objets.
Pour le reste, il y a shared_ptr.
Il suffit de lire Exceptional C++ ou bien quelques items de GotW pour se rendre compte que dans un milieu C++ gavés d'exception, il devient très dur d'écrire un programme qui se comporte correctement.
Avec les outils de gestion des ressources comme auto_ptr, shared_ptr, vector, etc... ça devient nettement plus facile.

[guillaume07]

citation de boost.org

Il y a des cas où il vaut mieux utiliser des pointeurs nus???

oui dans un code très critique niveau performance

[Goten]

Niveau perf? La lenteur d'une allocation est déjà problèmatique si t'as ce genre de contrainte.. sachant que si t'utilises make_shared tout est alloué en un bloc..

[Ubiquité]

Si tu crées et détruit des pointeurs très très très fréquemment.

[guillaume07]

Niveau perf? La lenteur d'une allocation est déjà problèmatique si t'as ce genre de contrainte.. sachant que si t'utilises make_shared tout est alloué en un bloc..

ça peut cependant être une contrainte incompréssible et tu seras plus rapide à faire du raw new qu'à faire du shared_ptr

[3DArchi]

Je suis comme Goten. Je serais curieux de voir cette idée de perf développée. Dans une allocation/libération, ce qui va coûter, c'est l'allocation ou la libération, le compteur de référence est lui assez peu cher.
Quand on est en pb de perf, on ne fait pas d'allocation en général.

[guillaume07]

Je n'ai malheureusement pas d'exemple sous la main, je parlais d'une manière générale

[JolyLoic]

Je ne pense pas qu'il y ait de différences notables en terme de performances à la création. Maintenant, il est vrai que :
- Ça augmente la taille des objets, donc c'est moins bon pour le cache si les objets sont très petits à la base.
- Ça peut avoir un impact au moment de la copie des pointeurs/destruction (il faut synchroniser l'incrément/décrément du compteur de référence).

Bien entendu, ces impact sont généralement négligeables.

Il y a par contre des cas où je n'utiliserais pas de shared_ptr, car ils n'auraient pas la bonne sémantique. Mais ça ne veut pas dire que j'utiliserais des pointeurs nus pour autant.

Finalement, là où j'utilise le plus de pointeurs nus, c'est pour m'interfacer avec du code en C (API windows, par exemple). Et c'est à chaque fois douloureux et bugogène.

[guillaume07]

c'est quand même pas compliqué de gérer des raw pointeur!
faut pas non plus exagérer! mon dernier projet à je ne sais pas combien de ligne de code, il fait tout:

- interface graphique complexe
- multi thread
- fichier
- base de données
- socket

je travaille quasiment uniquement avec une sémantique par adresse via l'utilisation de pointeur et je n'ai aucun bug ni memory leaps!

un new = un delete, c'est jamais plus compliqué

[Goten]

c'est quand même pas compliqué de gérer des raw pointeur!
faut pas non plus exagérer! mon dernier projet à je ne sais pas combien de ligne de code, il fait tout:

- interface graphique complexe
- multi thread
- fichier
- base de données
- socket

je travaille quasiment uniquement avec une sémantique par adresse via l'utilisation de pointeur et je n'ai aucun bug ni memory leaps!

un new = un delete, c'est jamais plus compliqué

Va dire ça a des années de logiciels qui leak comme pas possible . (sous entendu, non c'est pas aussi simple.. à fortiori dans un contexte MT).
Après personne dis que c'est infaisable, juste que c'est error prone, moche et lourd. (suffit de voir la tête d'un code pour proprement gérer une allocation dynamique d'un tableau.)
Et je te parle même pas d'exception safety... là ça devient drôle.

[guillaume07]

Va dire ça a des années de logiciels qui leak comme pas possible . (sous entendu, non c'est pas aussi simple.. à fortiori dans un contexte MT).
Après personne dis que c'est infaisable, juste que c'est error prone, moche et lourd. (suffit de voir la tête d'un code pour proprement gérer une allocation dynamique d'un tableau.)
Et je te parle même pas d'exception safety... là ça devient drôle.

ok mais moche et lourd.. voir des boost::shared_ptr<..> partout dans le code, je trouve ça justement moche et lourd.
y a qu'à voir dans l'implémentation des biliothèques boost on retrouve des pointeurs ou itérateurs partout dans le code


au hasard:

Code :

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

1
2
3
4
5
6
7
8
9
 
namespace boost {
  class bad_any_cast;
  class any;
  template<typename T> T any_cast(any &);
  template<typename T> T any_cast(const any &);
  template<typename ValueType> const ValueType * any_cast(const any *);
  template<typename ValueType> ValueType * any_cast(any *);
}

les pointeurs pour les durs, les vraies.
bjarne kholigus

[Joel F]

Sauf que la, mauvais exemple vu qu'il s'agit de fonction d'adaptation d'interface.

[guillaume07]

bon