Pimpl idiome vs classe virtuelle Pure interface

Pointer to implementation est habituellement d'environ cacher structurels détails de mise en œuvre. Interfaces sont sur l'instanciation des implémentations différentes. Ils ont vraiment servir à deux fins.

J'étais à la recherche d'une réponse à la même question.
Après la lecture de certains articles et de certaines pratiques , je préfère utiliser "classe virtuelle Pure interfaces".

1. Ils sont plus bourrin (c'est un avis subjectif). Pimpl idiome me fait sentir que je suis en train d'écrire du code "pour le compilateur", non pour la prochaine "développeur" qui va lire mon code.
2. Quelques tests des cadres de soutien direct de la Moquerie pure classes virtuelles
3. Il est vrai que vous besoin une usine pour être accessible de l'extérieur.
   Mais si vous voulez bénéficier du polymorphisme: c'est aussi "pro", pas un "con". ...et une simple méthode de fabrique n'a pas vraiment fait mal tellement

Le seul inconvénient (je suis en train d'enquêter sur cette), c'est que pimpl idiome pourrait être plus rapide

1. lorsque le proxy-appels sont intégrées, tout en héritant nécessairement besoin d'un accès supplémentaire à l'objet VTABLE au moment de l'exécution
2. la mémoire de l'pimpl public-proxy-classe est plus petit (vous pouvez le faire facilement des optimisations pour accélérer à des swaps et d'autres optimisations)

Il y a un réel problème avec les bibliothèques partagées qui le pimpl idiome contourne soigneusement que pure virtuals ne peut pas: vous ne pouvez pas sûre de modifier/supprimer les données membres d'une classe sans obliger les utilisateurs de la classe de recompiler le code. Qui peut être acceptable dans certaines circonstances, mais pas par exemple pour les bibliothèques système.

Pour expliquer le problème en détail, considérons le code suivant dans votre bibliothèque partagée/en-tête:

//header
struct A
{
public:
  A();
  //more public interface, some of which uses the int below
private:
  int a;
};

//library 
A::A()
  : a(0)
{}

Le compilateur émet le code dans la bibliothèque partagée qui calcule l'adresse de l'entier à être initialisée à être un certain décalage (probablement à zéro dans ce cas, car il est le seul membre) à partir du pointeur à Un objet qu'il connaît pour être this.

Du côté de l'utilisateur du code, un new A va allouer sizeof(A) octets de mémoire, puis à la main un pointeur vers la mémoire de la A::A() constructeur comme this.

Si dans une révision ultérieure de votre bibliothèque, vous décidez d'abandonner l'entier, de le rendre plus grand, plus petit, ou ajouter des membres, il y a un décalage entre la quantité de mémoire de l'utilisateur du code alloue, et les décalages le code du constructeur attend. Le résultat probable est un accident, si vous avez de la chance - si vous êtes moins chanceux, votre logiciel se comporte bizarrement.

Par pimpl require, vous pouvez ajouter et supprimer des membres de données à l'intérieur de la classe, comme l'allocation de la mémoire et de l'appel du constructeur arriver dans la bibliothèque partagée:

//header
struct A
{
public:
  A();
  //more public interface, all of which delegates to the impl
private:
  void * impl;
};

//library 
A::A()
  : impl(new A_impl())
{}

Tout ce que vous devez faire maintenant est de garder votre interface publique libre de membres de données autres que le pointeur de la mise en œuvre de l'objet, et vous êtes sûr de cette classe d'erreurs.

Edit: je devrais peut-être ajouter que la seule raison pour laquelle je parle du constructeur ici, c'est que je ne veux pas donner de code plus la même argumentation s'applique à toutes les fonctions d'accès aux données membres.

Bien que largement couverte par les autres réponses peut-être que je peux être un peu plus explicite au sujet de l'avantage de pimpl plus virtuel classes de base:

Un pimpl approche est transparent du point de vue de l'utilisateur, ce qui signifie que vous pouvez par exemple créer des objets de la classe sur la pile et de les utiliser directement dans des conteneurs. Si vous essayez de masquer la mise en œuvre à l'aide d'un résumé virtuel de la classe de base, vous aurez besoin de retourner un pointeur partagé de la classe de base de l'usine, ce qui complique son utilisation. Considérons le schéma équivalent suivant le code de client:

//Pimpl
Object pi_obj(10);
std::cout << pi_obj.SomeFun1();

std::vector<Object> objs;
objs.emplace_back(3);
objs.emplace_back(4);
objs.emplace_back(5);
for (auto& o : objs)
    std::cout << o.SomeFun1();

//Abstract Base Class
auto abc_obj = ObjectABC::CreateObject(20);
std::cout << abc_obj->SomeFun1();

std::vector<std::shared_ptr<ObjectABC>> objs2;
objs2.push_back(ObjectABC::CreateObject(13));
objs2.push_back(ObjectABC::CreateObject(14));
objs2.push_back(ObjectABC::CreateObject(15));
for (auto& o : objs2)
    std::cout << o->SomeFun1();

Dans ma compréhension de ces deux choses servent objectifs complètement différents. Le but de la pimple idiome est essentiellement de vous donner une poignée pour votre application de sorte que vous pouvez faire des choses comme rapide des swaps pour un tri.

Le but de classes virtuelles est plus le long de la ligne de permettre le polymorphisme, c'est à dire que vous avez un inconnu pointeur vers un objet de type dérivé et lorsque vous appelez la fonction x-vous de toujours avoir la bonne fonction pour quelle que soit la classe le pointeur de la base en fait des points d'.

Les pommes et les oranges vraiment.