57 votes

C ++11: Remplacez tous les pointeurs bruts non propriétaires par std :: shared_ptr ()?

Avec l'avènement de l' std::unique_ptr, les imperfections std::auto_ptr peuvent enfin être mis au repos. Donc, depuis quelques jours, j'ai changé mon code pour utiliser des pointeurs intelligents et d'éliminer tous delete de mon code.

Bien que valgrind me dit que mon code est en mémoire propre, la richesse sémantique des pointeurs intelligents contribueront à rendre plus simple et plus facile à comprendre le code.

En plus du code, la traduction est simple: utiliser std::unique_ptr de en lieu de la première pointeurs tenu par la possession d'objets, jetez delete, et soigneusement saupoudrer get(), reset() et move() des appels, en tant que de besoin, à l'interface bien avec le reste du code.

J'en suis au point où je suis la traduction de la non-possession d'raw pointeurs de pointeurs intelligents maintenant.

Depuis que j'ai été prudent avec la durée de vie de mes objets (je m'assurer que mes modules dépendent dans une seule direction), valgrind me dit que je n'ai pas non initialisée lit, balançant des pointeurs ou des fuites. Donc, techniquement, je pourrais juste laisser les non-possesseurs d'un raw pointeurs seul maintenant.

Toutefois, une option est de changer les non-possesseurs d'un raw pointeurs d' std::shared_ptr parce que je sais qu'ils sont acycliques. Ou, serait-il mieux de les laisser brutes des pointeurs?

J'ai besoin de quelques conseils de la part du vétéran utilisateurs de smart pointeurs à ce que les règles de base que vous utilisez pour décider de conserver non propriétaire raw pointeurs comme-est, ou de les traduire en std::shared_ptr, en gardant à l'esprit que j'ai constamment des tests unitaires et valgrind mon code.

EDIT: j'ai peut-être l'incompréhension de l'utilisation de std::shared_ptr - peuvent-ils être utilisés en conjonction avec d' std::unique_ptr, ou bien, est-ce que si j'utilise std::shared_ptr,, toutes les poignées doivent également être std::shared_ptr?

106voto

Dave Points 10916

Personnellement, c'est comment j'ai (plus ou moins) à faire:

  • unique_ptrs sont de la propriété exclusive
  • raw pointeurs dire celui qui m'a donné le pointeur brut garantit la durée de vie de cet objet afin d'égaler ou de surpasser ma vie.
  • shared_ptrs sont le partage de la propriété
  • weak_ptrs sont pour un système veut vérifier si l'objet existe toujours avant de l'utiliser. C'est rare dans mon code car je trouve ça plus propre d'avoir un système de garantie de la durée de vie de tout ce qu'il passe, il est sous-systèmes (dans ce cas, j'utilise un pointeur brut)

De loin, j'utilise plus unique_ptrs que shared_ptrs, et plus de matières premières pointeurs de pointeurs faibles.

11voto

GManNickG Points 155079

Utiliser un shared_ptr lorsque vous avez besoin de plusieurs choses propres à une ressource (et ceux de posséder les choses peuvent se passer dans et hors de portée à "aléatoire"), l'utilisation d'un unique_ptr lorsqu'une seule chose est propriétaire de la ressource et de l'utilisation d'un pointeur brut lorsque vous avez simplement besoin de se référer à elle et de ne pas le posséder (et s'attendre à ce renvoi à ne pas durer plus longtemps que la ressource existe).

Il existe un quatrième type, une sorte de brute-pointeur-pour-shared_ptrs', appelés weak_ptr. Vous utilisez que pour faire référence à un shared_ptr sans en être propriétaire; vous pouvez ensuite vérifier si l'objet est toujours là et l'utiliser.

8voto

ltjax Points 11115

Le seul non-propriétaire de smart-pointeur dans la bibliothèque standard est std::weak. Cependant, l'utiliser, le réel de l'objet propriétaire doit tenir à la pointee dans un std::shared_ptr.

Je suppose que vous avez utilisé std::unique_ptr sur ceux d'avant. Si vous les convertir en shared_ptr maintenant, vous aurez l'avantage que votre non propriétaire des pointeurs peut savoir qui est le propriétaire du pointeur de perdu, c'est la référence tandis que raw pointeurs peut être laissé balançant sans aucune possibilité pour les non-possesseurs d'un composant afin de détecter cela. Cependant, shared_ptr entraînera une (très?) petite performance et la surcharge de la mémoire de plus de unique_ptr.

Personnellement, je recommande d'utiliser un shared_ptr et de nombreux weak_ptrs au lieu d'un unique_ptr et beaucoup de matières premières-les pointeurs dans le cas général, et de l'utilisation unique_ptr si vous avez vraiment un problème de performances!

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X