Pour obtenir le comptage des références, dois-je encombrer mes API avec shared_ptr?

Question

J'ai eu récemment le bug de mémoire suivante, qui est facile à repérer, mais peut être plus difficile à détecter dans le code plus complexe:

class Foo : public IFoo { 
    const Bar& bar_; 
public: 
    Foo(const Bar& bar) : bar_(bar) { 
    } 
    void test() { 
    // access bar_ here 
    } 
}; 

int baz() { 
    IFoo* foo = NULL; 
    if(whatever) { 
    Bar bar; 
    foo = new Foo(bar); 
    } 
    else { 
    // create other foo's 
    } 
    foo->test(); // segmentation fault 
} 

Le bug est que Bar immédiatement est hors de portée, est détruit puis utilisé dans foo->test(). Une solution consiste à créer Bar sur le tas, en utilisant Bar* bar = new Bar(). Cependant, je n'aime pas faire cela parce que je devrais garder le pointeur Bar* bar au niveau supérieur pour que je puisse y accéder et delete à la fin, même si Bar est quelque chose qui est spécifique à ce bloc de code particulier if(whatever){}.

Une autre solution est boost::shared_ptr<Bar>, mais je ne peux pas écrire ceci:

if(whatever) { 
    boost::shared_ptr<Bar> bar(new Bar()); 
    foo = new Foo(*bar); 
    } 

depuis le shared_ptr est hors de portée immédiatement, aussi, détruire l'objet contenu.

Donc en bref, pour se débarrasser de ce problème, je dois utiliser shared_ptr partout, en Foo comme variable membre, dans le constructeur de Foo, etc. Pour éliminer ces problèmes en général, toutes mes API etc doivent utiliser shared_ptr, ce qui est un peu moche. Mais, est-ce la bonne chose à faire? Jusqu'à présent, je l'ai utilisé parfois pour créer des objets comptés par référence, mais j'ai gardé mes API propres de shared_ptr. Comment gérez-vous ce problème que, une fois que vous utilisez shared_ptr vous devez l'utiliser partout?

(De plus, si vous utilisez ces pointeurs de référence compté, vous devez commencer à se soucier si vous voulez vraiment shared_ptr ou plutôt weak_ptr etc.)

Et, qu'est-ce que j'utiliser comme un équivalent à Foo(const Bar& bar)? Foo(const shared_ptr<const Bar> bar)? Une autre option, bien sûr, est d'ajouter vous-même le comptage des références à l'intérieur du Bar et d'autres objets, en utilisant pimpl et vos propres compteurs, mais cela devient en général trop fastidieux.

Answer 1

En fait, je utiliser shared_ptr partout ... Il y a plusieurs façons de le rendre moins encombré. Une convention que j'utilise est typedefs pour chaque classe définie:

class AClass { 
public: 
    typedef boost::shared_ptr<AClass> Ptr; 
    typedef boost::weak_ptr<AClass> Ref; 
    //... 
}; 

rend le code beaucoup plus lisible :)

En ce qui concerne votre problème, rappelez-vous que vous pouvez passer la barre par pointeur - vous auriez pour se rappeler de l'allouer sur le tas si.

Answer 2

Il serait préférable de ne pas passer la barre byref dans Foo (en d'autres termes, changer le constructeur de Foos) ou de le copier afin de conserver une copie dans Foo. Bien sûr, dans certains cas, ce n'est pas possible. En ce qui concerne couvrir votre code avec shared_ptr<Bar>, la solution la plus simple est de typedef shared_ptr<Bar> à BarPtr ou similaire.

Answer 3

Vous pouvez simplement déplacer votre objet barre à une portée plus élevée afin d'empêcher sa suppression trop tôt.

int baz() { 
    Bar bar; 
    IFoo* foo = NULL; 
    if(whatever) { 
    foo = new Foo(bar); 
    } 
    else { 
    // create other foo's 
    } 
    foo->test(); // no more segmentation fault 
} 

Answer 4

Je comprends que vous fournissez une version simplifiée de votre code, et sans voir le reste, je ne sais pas si ce que je dis est maintenant possible.

Depuis foo est l'objet le plus long vivant, comment sur la création de l'instance Bar à l'intérieur, et de faire d'autres références variables (bar dans votre code) à ce sujet? D'autre part, si Bar est vraiment spécifique à l'intérieur du bloc if, test() ne devrait pas du tout en avoir besoin. Dans ce cas, il n'y a aucun problème à garder un pointeur à l'intérieur de Foo puis de le supprimer à la fin du bloc if. Sinon, ce n'est peut-être pas si spécifique au bloc et vous devez repenser un peu votre conception.

Answer 5

je fait proposer une autre solution ...

Je ne aime vraiment référence sans compter que beaucoup, non seulement l'encombrement, mais aussi parce qu'il est plus difficile de raisonner lorsque plusieurs objets ont une poignée au même élément .

class IBar 
{ 
public: 
    virtual ~IBar() {} 
    virtual IBar* clone() const; 
}; 

class Foo: public IFoo 
{ 
public: 
    Foo(const IBar& ibar): m_bar(ibar.clone()) {} 
    Foo(const Foo& rhs): m_bar(rhs.m_bar->clone()) {} 
    Foo& operator=(const Foo& rhs) { Foo tmp(rhs); this->swap(tmp); return *this; } 
    virtual ~Foo() { delete m_bar; } 

    void swap(Foo& rhs) { std::swap(m_bar, rhs.m_bar); } 

private: 
    IBar* m_bar; 
}; 

Et maintenant votre code fonctionne, parce que je fait une copie :)

Bien sûr, si la barre était pas polymorphes, il serait alors beaucoup plus facile. Donc, même s'il n'utilise pas de référence, êtes-vous sûr d'en avoir réellement besoin?

---

Obtenons hors piste maintenant, parce qu'il ya un certain nombre de choses que vous avez tort: ​​

• foo = new Foo(bar) n'est pas assez, comment allez-vous garantir que la mémoire est supprimée dans le cas où un exception se produit ou introduit quelque peu return dans le fouillis if? Vous devez vous déplacer vers un objet qui gère la mémoire pour vous auto_ptr ou le nouveau unique_ptr à partir de C++ 0x ou Boost. Au lieu d'utiliser le comptage des références, pourquoi le Foo ne prend-il pas en charge le code
• ? Foo(std::auto_ptr<Bar> bar) fonctionnerait aussi.

Shy de la référence de comptage où ce n'est pas nécessaire. Chaque fois que vous partager quelque chose que vous introduisez réellement une source de bogues difficiles à suivre dans votre code (et potentiellement des effets secondaires). Voilà pourquoi Haskell et la famille fonctionnelle gagnent en popularité :)

Answer 6

De plus, si vous utilisez ces pointeurs compté référence, vous devez commencer à se soucier si vous voulez vraiment shared_ptr ou plutôt weak_ptr etc

Il n'y a aucun souci si vous suivez votre conception et vous comprenez ce qui est weak_ptr (indice: ce n'est pas une référence) et à quoi cela sert (indice: ce n'est pas pour "casser des cycles").

Si vous commencez à vous inquiéter, c'est parce que vous n'avez jamais eu de design, ou que vous ne comprenez pas le design shared_ptr.