Comptage de référence en C++ OO-Style

Est-ce une alternative viable à l'pointeur intelligent approche pour la gestion de la durée de vie des objets, ou est-il juste d'avoir des ennuis?

Non, je ne pense pas que c'est une bonne idée de réinventer le comptage de référence, surtout depuis que nous avons std::shared_ptr maintenant en C++11. Vous pouvez facilement mettre en œuvre vos éventuellement polymorphe de référence compté Pimpl idiome de la classe en termes de std::shared_ptr. Remarquez comment nous n'avons pas à mettre en œuvre copier ctor, de cession, de dtor plus et la mutation devient plus simple.w.r.t. le compteur de référence et le clonage:

//to be placed into a header file ...
#include <memory>
#include <utility>
#include <string>
class Fred
{
public:
static Fred create1(std::string const& s, int i);
static Fred create2(float x, float y);
void sampleInspectorMethod() const;   //No changes to this object
void sampleMutatorMethod();           //Change this object
private:
class Data;
std::shared_ptr<Data> data_;
explicit Fred(std::shared_ptr<Data> d) : data_(std::move(d)) {}
};

...et la mise en œuvre...

//to be placed in the corresponding CPP file ...
#include <cassert>
#include "Fred.hpp"
using std::shared_ptr;
class Fred::Data
{
public:
virtual ~Data() {}                               //A virtual destructor
virtual shared_ptr<Data> clone() const = 0;      //A virtual constructor
virtual void sampleInspectorMethod() const = 0;  //A pure virtual function
virtual void sampleMutatorMethod() = 0;
};
namespace {
class Der1 : public Fred::Data
{
public:
Der1(std::string const& s, int i);
virtual void sampleInspectorMethod() const;
virtual void sampleMutatorMethod();
virtual shared_ptr<Data> clone() const;
...
};
//insert Der1 function definitions here
class Der2 : public Data
{
public:
Der2(float x, float y);
virtual void sampleInspectorMethod() const;
virtual void sampleMutatorMethod();
virtual shared_ptr<Data> clone() const;
...
};
//insert Der2 function definitions here
} //unnamed namespace
Fred Fred::create1(std::string const& s, int i)
{
return Fred(std::make_shared<Der1>(s,i));
}
Fred Fred::create2(float x, float y)
{
return Fred(std::make_shared<Der2>(x,y));
}
void Fred::sampleInspectorMethod() const
{
//This method promises ("const") not to change anything in *data_
//Therefore we simply "pass the method through" to *data_:
data_->sampleInspectorMethod();
}
void Fred::sampleMutatorMethod()
{
//This method might need to change things in *data_
//Thus it first checks if this is the only pointer to *data_
if (!data_.unique()) data_ = data_->clone();
assert(data_.unique());
//Now we "pass the method through" to *data_:
data_->sampleMutatorMethod();
}

(non testé)

Si c'est approprié, pourquoi supposez-vous qu'il n'est pas utilisé plus souvent?

Je pense que le comptage de référence, si vous mettez en place vous-même, il est plus facile de se tromper. Il a aussi la réputation d'être lent dans multithread environnements, car les compteurs de référence doivent être incrémenté et décrémenté de manière atomique. Mais je suppose en raison de C++11 qui propose des shared_ptr et la sémantique de déplacement, cette copie sur écriture motif peut être un peu plus populaire encore. Si vous activez la sémantique de déplacement pour le Fred classe, vous pouvez éviter une partie des coûts de atomiquement de l'incrémentation des compteurs de référence. Donc le déplacement d'un objet Fred d'un endroit à un autre devrait être encore plus rapide que de copier.

OriginalL'auteur sellibitze

Moi aussi, je me demande si c'est approprié comme une alternative de pointeur intelligent.

Mais, de l'OMI, à être un pointeur intelligent, une classe doit être utilisable comme un pointeur c'est à dire :

SmartPtr<int> ptr = new int(42);
int x = *ptr;

Donc, oui, il une sorte de gestion de la mémoire, mais ce n'est pas un pointeur intelligent, car il n'a pas la sémantique d'un pointeur.

Comme mentionné dans les commentaires, le pimpl idiome est vraiment très utile pour le maintien de la compatibilité et il peut aussi favoriser le développement que vous n'avez pas à recompiler le contenant de la classe.
MAIS avoir le dernier avantage, vous ne devez pas définir à l'intérieur de la classe (c'est à dire des Données) à l'intérieur de la classe parent, mais plutôt de mettre juste une déclaration de l'avant et mettre de la définition réelle à l'intérieur d'un autre en-tête.

class Fred {
...
private:
class Data;
};

Et, je trouve pas ça utile pour le développement futur de déclarer variante de Données à l'intérieur de la classe Fred, parce que si vous avez besoin d'ajouter une autre classe, vous aurez besoin de modifier Fred au lieu de simplement créer une autre classe. Cela pourrait être voulu, mais je vous suggère d'éviter que la partie.

Si je n'étais pas clair à propos de quelque chose, n'hésitez pas à poser des questions!

OriginalL'auteur fstamour