shared_ptr vs scoped_ptr

Question

scoped_ptr n'est pas de copie de mesure et est supprimé de la portée. Donc, il est assez restreint shared_ptr. Donc, semble d'ailleurs le cas où vous avez vraiment besoin de restreindre l'opération de copie, shared_ptr est le meilleur à utiliser. Parce que parfois vous ne savez pas, vous devez créer une copie de votre objet ou pas. La question est donc: outre les cas mentionnés ci-dessus, ne pourrait-on considérer qu' shared_ptr est mieux (ou recommandé) d'utiliser à la place de scoped_ptr. N' scoped_ptr de travailler beaucoup plus vite à partir de shared_ptr, ou a-t-elle des avantages?

Merci!

Answer 1

shared_ptr est plus lourd que l' scoped_ptr. Il a besoin d'allouer et de libérer un nombre de références d'objet ainsi que l'objet géré, et de gérer les thread-safe de comptage de référence - sur une plate-forme sur laquelle je travaillais, c'était une surcharge importante.

Mon avis (en général) est l'utilisation la plus simple de l'objet qui répond à vos besoins. Si vous avez besoin de référence compte de partage, l'utilisation shared_ptr; si vous avez juste besoin de suppression automatique une fois que vous avez terminé avec une seule référence, utilisez scoped_ptr.

Answer 2

Performance - shared_ptr a plus de fonctionnalités, mais nécessite également une allocation supplémentaire (elle est également plus grande, mais cela importe rarement).

Expression de l'intention en utilisant scoped_ptr vous énoncez plus explicitement ce que vous voulez faire. (Au cas où vous vous demandez - c'est une bonne chose :)). Si vous le faites correctement, shared_ptr indiquera également "cet objet est destiné à vivre au-delà de cette portée"

Answer 3

Leur objectif est différent, donc, dans de nombreux cas, "shared_ptr vs scoped_ptr" n'est pas du tout une question. Bien sûr, vous pouvez utiliser un shared_ptr lorsque tout ce dont vous avez besoin est un scoped_ptr. Mais à quoi ça sert? shared_ptr a probablement un surcoût légèrement plus important avec tous les comptages de références impliqués.

Answer 4

scoped_ptr fonctionne beaucoup plus rapidement de shared_ptr . C'est juste. shared_ptr alloue toujours la mémoire à l'aide de votre allocateur ou de l'allocateur par défaut.

Answer 5

Scoped_ptr a peu en commun avec shared_ptr, weak, ou unique_ptr parce que c'est seulement à faire le cas très particulier de "comptage de référence". Ce n'est pas quelque chose que vous devrez très souvent bien conçus code, mais c'est un bon outil à avoir disponible.

Fondamentalement, un scoped_ptr n'est pas une référence compté chose. Plutôt, c'est un objet que vous créez sur la pile (à l'intérieur de la portée locale), de sorte que vous pouvez faire quelque chose comme ceci:

  //Some enclosing scope- anything set off by "{}" or even a function:
   {
       scoped_ptr<MyObject> ptr = new MyObject( parameters...);
   } // When we hit this closing brace, "ptr" will delete the "MyObject" inside.

Vous avez tendance à voir cette tendance est plus avec les mutex et les autres de synchronisation primatives - je peux déclarer un "verrouillage automatique" qui permet de verrouiller le mutex passés dans celui-ci, puis déverrouiller lorsqu'il supprime tout "{}" étendue dans une section critique.

Notez également qu'un "scoped_ptr' n'a jamais de sens que si vous ne pouvez pas simplement faire un bon vieil allocation de pile comme "Monobjet obj(params..)" pour une raison quelconque. Après tout, ce qu'il fait est ce qui vous permet d'utiliser un segment de mémoire alloué par l'objet comme s'il était l'un sur la pile. Qui tend à être beaucoup plus rare, un cas d'utilisation que le comptage de références de shared_ptr & ses cousins.