Dois-je utiliser shared_ptr ou unique_ptr

J'ai fait quelques objets à l'aide de la pimpl idiome, mais je ne suis pas sûr que d'utiliser std::shared_ptr ou std::unique_ptr.

Je comprends que std::unique_ptr est plus efficace, mais ce n'est pas tellement un problème pour moi, car ces objets sont relativement lourds, de sorte que les coûts de std::shared_ptr sur std::unique_ptr est relativement mineur.

Je suis actuellement en cours avec std::shared_ptr juste à cause de la plus grande flexibilité d'utilisation. Par exemple, à l'aide d'un std::shared_ptr me permet de stocker ces objets dans une table de hachage pour un accès rapide tout en étant capable de retourner les copies de ces objets pour les appelants (comme je le crois, tout itérateurs ou références peuvent rapidement devenir invalide).

Cependant, ces objets ne sont vraiment pas être copié, que les modifications portent sur l'ensemble des copies, donc je me demandais que peut-être l'aide d' std::shared_ptr et permettant des copies est une sorte d'anti-modèle ou une mauvaise chose.

Est-ce correct?

  • À l'aide de l'une ou l'autre change profondément la sémantique de copie que vous donnez à vos objets. Il y a utilise pour les deux. Je dirais que le plus idiomatique dans le C++ monde est unique_ptr, mais l'objet qui partagent un implémentations ont à leur utilisation, en particulier si vous êtes l'écriture de "l'étranger" de code (par exemple. COM, C++/CLI), ou si la classe ressemble vraiment à un "type de référence".
  • Question similaire: stackoverflow.com/questions/311166/...
  • La manière recommandée en C++11 est à usage unique, après tout, vous n'avez pas besoin de copier ou partager l'application avec n'importe qui. Aussi unique_ptr est plus rapide au moment de l'exécution.
InformationsquelleAutor Clinton | 2011-04-07
  1. 36

    J'ai fait quelques objets à l'aide de la pimpl idiome, mais je ne sais pas si utilisé shared_ptr ou unique_ptr.

    Certainement unique_ptr ou scoped_ptr.

    Pimpl n'est pas un modèle, mais un idiome, qui traite de la compilation de la dépendance du temps et de la compatibilité binaire. Il ne devrait pas affecter la sémantique des objets, en particulier en ce qui concerne sa copie comportement.

    Vous pouvez utiliser quel que soit le type de pointeur intelligent que vous voulez sous le capot, mais ces 2 la garantie que vous ne serez pas accidentellement partager la mise en œuvre entre deux objets distincts, car ils nécessitent une décision consciente à propos de la mise en œuvre du constructeur de copie et l'opérateur d'affectation.

    Cependant, ces objets ne sont vraiment pas être copié, que les modifications portent sur l'ensemble des copies, donc je me demandais que peut-être l'aide d' shared_ptr et permettant des copies est une sorte d'anti-modèle ou une mauvaise chose.

    Il n'est pas un anti-modèle, en fait, il s'agit d'un modèle: l'Aliasing. Vous utilisez déjà, en C++, avec les pointeurs et références. shared_ptr offrent une mesure de "sécurité" pour éviter les morts références, au coût supplémentaire de complexité et de nouvelles questions (attention aux cycles de créer des fuites de mémoire).

    Sans rapport avec Pimpl

    Je comprends unique_ptr est plus efficace, mais ce n'est pas tellement un problème pour moi, car ces objets sont relativement lourds, de sorte que les coûts de shared_ptr sur unique_ptr est relativement mineur.

    Si vous pouvez tenir compte de l'état, vous pouvez prendre un coup d'oeil à la Poids mouche modèle.

    • Donc, vous êtes en train de dire que normalement, copier les constructeurs devraient faire profonde des copies (ou quelque chose d'équivalent sur le plan fonctionnel, c'est à dire la copie sur écriture) à l'exception de pointeurs/pointeurs intelligents?
    • du point de vue sémantique, une copie est séparé de sa source, et les détails de mise en œuvre sont d'aucun intérêt pour l'utilisateur 🙂 En C++ ce n'est pas le cas pour les pointeurs et les références, mais le vocabulaire n'a jamais été vraiment adapté, donc la maladresse lors de la discussion de ces aspects. .. Si dans votre cas vous préférez une copie en profondeur ou un peu profond, la copie ne doit dépendent de la sémantique que vous souhaitez donner à votre classe, et la mise en œuvre suivra suite.
    • +1 pour scoped_ptr
    • "pourtant, le vocabulaire n'a jamais été vraiment adapté" Que voulez-vous dire?
    • 5 mois après 😡 ? Je pense que mon point était qu'une "copie" du constructeur de faire une copie superficielle était un peu bizarre, mais vraiment... je ne suis pas sûr :p
    • Dans certains cas exceptionnels, vous souhaitez utiliser shared_ptr, en fait. Vous voudrez peut-être un objet Foo dont la mise en œuvre peut être partagée entre plusieurs Foo objets, à l'aide de comptage de référence et de copie sur écriture de la sémantique.
    • La VACHE est une option (et je n'ai dit que shared_ptr a été adapté à certains cas), mais nous parlions de Pimpl ici; ce n'est pas un de ces cas où shared_ptr est adapté.
    • Quelle est la différence entre un "modèle" et un "idiome"?
    • La définition que j'applique est qu'un motif est quelque chose qui est utile dans un grand nombre de langues (par exemple, les célèbres Modèles de Conception de la bande des Quatre s'appliquent à toutes les langues dans lesquelles vous pouvez utiliser orientée objet, les dessins ou modèles), alors qu'un langage est spécifique à une langue spécifique (ou un tout petit peu). PIMPL s'agit précisément d'un C ou C++ idiome, comme il a été créé pour tailler les fichiers d'en-tête.
    • Eh bien, vous avez droit à votre opinion, mais en gros, vous prétendre que les PFI n'existe pas. Peut-être il y a un "CRTI". Je ne suis pas sûr que ce soit une commune ou, de l'avis raisonnable ou de la définition.
    • PFI n'est pas spécifique à C ou C++, je m'attends il peut être utilisé dans D au moins et éventuellement en Java/C# (pas sûr, comme il semble en avoir besoin sans les contraintes génériques). Dans tous les cas, les conditions certainement se chevauchent, et d'autres personnes ont des opinions différentes de leur sens, ... c'est un peu le bazar 😡
    • En va de même pour pimpl. Il n'est pas non plus spécifique au C++. Il peut aussi être utilisé dans D. dlang.org/spec/struct.html stackoverflow.com/questions/20469768/...
    • La page que vous lien vers l'appelle le PIMPL idiome 😉 En tout cas, juste parce que c'est utilisable en D sur le dessus de C ou C++ ne prend pas nécessairement la violation de ma définition; c'est encore une niche.
    • Mais que la page web ne fait pas valoir que "l'idiome" et "pattern" sont mutuellement exclusifs comme vous l'avez fait. PIMPL est utilisable dans D "en haut de la C" de même que le PFI est disponible dans D "en haut de la lettre C et en C#/Java "par-dessus" un des génériques de la syntaxe copié directement à partir de C++. Lorsque vous changez votre définition c'est un signe que vous foiré. Vous d'abord décidé que "l'idiome" et "pattern" sont mutuellement exclusifs, et ne cherche pas à inventer une définition qui permettrait de le faire fonctionner. Des beaux. Je l'ai eu.

    InformationsquelleAutor Matthieu M.
  2. 10

    Si vous utilisez shared_ptr, ce n'est pas vraiment le classique pimpl
    idiome (à moins que vous prendre des mesures supplémentaires). Mais la vraie question
    c'est pourquoi vous voulez utiliser un pointeur intelligent pour commencer; c'est très
    clair où l' delete devrait se produire, et il n'y a pas de problème de
    exception de sécurité ou d'autres à être concernés par. Tout au plus,
    un pointeur intelligent vous permettra d'économiser en une ou deux lignes de code. Et la
    seul à la sémantique correcte est boost::scoped_ptr,
    et je ne pense pas que cela fonctionne dans ce cas. (IIRC, il nécessite
    un type complètes pour être instancié, mais je pourrais être
    mal.)

    Un aspect important de la pimpl idiome est que son utilisation devrait être
    transparent pour le client; la classe doit se comporter exactement comme si
    il ont été mises en œuvre de façon classique. Cela signifie soit en inhibant la
    copie et de la cession ou de la mise en œuvre de copie en profondeur, à moins que la classe
    est immuable (pas de non-const fonctions de membre). Aucun d'habitude
    pointeurs intelligents mettre en œuvre copie en profondeur; vous pourriez mettre en œuvre, de
    bien sûr, mais il serait sans doute encore besoin d'une complète type
    chaque fois que la copie se passe, ce qui signifie que vous auriez toujours se
    fournir à un utilisateur défini constructeur de copie et l'opérateur d'affectation
    (puisqu'ils ne peuvent pas être en ligne). Compte tenu de cela, il n'est probablement pas
    vaut la peine en utilisant le pointeur intelligent.

    Une exception est si les objets sont immuables. Dans ce cas, il
    n'a pas d'importance si la copie est profonde ou pas, et shared_ptr
    les poignées de la situation complètement.

    InformationsquelleAutor James Kanze
  3. 5

    Lorsque vous utilisez un shared_ptr (par exemple dans un récipient, puis de regarder cela et le retourner par valeur), vous ne sont pas la cause d'une copie de l'objet et il points de, simplement une copie du pointeur avec un nombre de références.

    Cela signifie que si vous modifiez l'objet sous-jacent à partir de plusieurs points, alors vous influer sur les changements sur le même instance. C'est exactement ce qu'il est conçu, donc pas certains anti-modèle!

    Lors du passage d'un shared_ptr (comme les commentaires dire) c'est mieux de passer par référence const et copie (il y en incrémentant le nombre de références) en cas de besoin. Comme pour le retour, au cas par cas.

    • C'est un bon conseil, mais je pense que "passent toujours et retour par valeur" est un peu fort. La préférence est de passer par const référence ou référence rvalue. En passant par la plaine, modifiable de référence est même encore parfois approprié.
    • Ah, je pensais au sujet de l'effet du passage par valeur sur un objet avec un membre (pimpl) shared_ptr ou unique_ptr. Dans ce contexte, la smart pointeur lui-même ne devrait pas être passé autour.
    • Gerell: Non, vous avez pas censés passer shared_ptr en valeur. Vous pouvez, mais ce n'est pas la méthode recommandée. Il est recommandé de les faire passer par référence const. C'est à la fois plus efficace que la copie d'un shared_ptr et aussi absolument sûr, car les lectures simultanées de la même shared_ptr instance sont ok comme par le shared_ptr de la documentation.
    InformationsquelleAutor Nim
  4. 1

    Oui, veuillez les utiliser. Il suffit de mettre, le shared_ptr est une implémentation de pointeur intelligent. unique_ptr est une mise en œuvre automatique de pointeur:

    InformationsquelleAutor Trombe