L'idiome PIMPL est-il réellement utilisé dans la pratique ?

Question

Je suis en train de lire le livre "Un C++ exceptionnel" par Herb Sutter, et dans ce livre j'ai appris l'idiome PIMPL. En gros, l'idée est de créer une structure de private les objets d'une class et les allouer dynamiquement à diminuer le temps de compilation (et aussi cacher les implémentations privées d'une meilleure manière).

Par exemple :

class X
{
private:
  C c;
  D d;
} ;

pourrait être changé en :

class X
{
private:
  struct XImpl;
  XImpl* pImpl;
};

et, dans le fichier .cpp, la définition :

struct X::XImpl
{
  C c;
  D d;
};

Cela semble assez intéressant, mais je n'ai jamais vu ce genre d'approche auparavant, ni dans les entreprises où j'ai travaillé, ni dans les projets open source dont j'ai vu le code source. Je me demande donc si cette technique est réellement utilisée dans la pratique ?

Dois-je l'utiliser partout, ou avec prudence ? Et cette technique est-elle recommandée pour être utilisée dans les systèmes embarqués (où les performances sont très importantes) ?

Answer 1

Je me demande donc si cette technique est réellement utilisée dans la pratique ? Dois-je l'utiliser partout, ou avec prudence ?

Bien sûr qu'il est utilisé. Je l'utilise dans mon projet, dans presque tous les cours.

---

Raisons d'utiliser l'idiome PIMPL :

Compatibilité binaire

Lorsque vous développez une bibliothèque, vous pouvez ajouter/modifier des champs dans la bibliothèque. XImpl sans rompre la compatibilité binaire avec votre client (ce qui signifierait des plantages !). Puisque la disposition binaire de X ne change pas lorsque vous ajoutez de nouveaux champs à la classe Ximpl il est possible d'ajouter de nouvelles fonctionnalités à la bibliothèque dans les mises à jour mineures des versions.

Bien entendu, vous pouvez également ajouter de nouvelles méthodes non virtuelles publiques/privées à l'interface de l'UE. X / XImpl sans rompre la compatibilité binaire, mais cela correspond à la technique standard d'en-tête/implémentation.

Masquage des données

Si vous développez une bibliothèque, en particulier une bibliothèque propriétaire, il peut être souhaitable de ne pas divulguer quelles autres bibliothèques / techniques de mise en œuvre ont été utilisées pour mettre en œuvre l'interface publique de votre bibliothèque. Soit pour des questions de propriété intellectuelle, soit parce que vous pensez que les utilisateurs pourraient être tentés de faire des suppositions dangereuses sur l'implémentation ou de briser l'encapsulation en utilisant de terribles astuces de casting. PIMPL résout/atténue ce problème.

Temps de compilation

Le temps de compilation est réduit, puisque seul le fichier source (d'implémentation) de X doit être reconstruite lorsque vous ajoutez/supprimez des champs et/ou des méthodes à l'application XImpl (ce qui revient à ajouter des champs/méthodes privés selon la technique standard). En pratique, il s'agit d'une opération courante.

Avec la technique standard d'en-tête/implémentation (sans PIMPL), lorsque vous ajoutez un nouveau champ à l'élément X chaque client qui alloue X (soit sur la pile, soit sur le tas) doit être recompilé, car il doit ajuster la taille de l'allocation. Eh bien, chaque client qui n'alloue jamais X également doivent être recompilés, mais ce n'est qu'une surcharge (le code résultant du côté client sera le même).

De plus, avec la séparation standard en-tête/implémentation XClient1.cpp doit être recompilé même lorsqu'une méthode privée X::foo() a été ajouté à X y X.h a changé, même si XClient1.cpp ne peut pas appeler cette méthode pour des raisons d'encapsulation ! Comme ci-dessus, il s'agit d'une pure surcharge et elle est liée à la façon dont les systèmes de construction C++ fonctionnent dans la vie réelle.

Bien sûr, la recompilation n'est pas nécessaire lorsque l'on se contente de modifier l'implémentation des méthodes (car on ne touche pas à l'en-tête), mais cela correspond à la technique standard de l'en-tête/implémentation.

---

Cette technique est-elle recommandée pour être utilisée dans les systèmes embarqués (où les performances sont très importantes) ?

Cela dépend de la puissance de votre cible. Cependant, la seule réponse à cette question est : mesurez et évaluez ce que vous gagnez et perdez. Prenez également en compte le fait que si vous ne publiez pas une bibliothèque destinée à être utilisée dans des systèmes embarqués par vos clients, seul l'avantage du temps de compilation s'applique !

Answer 2

Il semble qu'un grand nombre de bibliothèques l'utilisent pour maintenir la stabilité de leur API, du moins pour certaines versions.

Mais comme pour toute chose, il ne faut jamais utiliser n'importe quoi partout sans précaution. Réfléchissez toujours avant de l'utiliser. Évaluez les avantages qu'il vous procure et voyez s'ils valent le prix que vous payez.

Les avantages qu'elle offre puede vous donner :

• aide à maintenir la compatibilité binaire des bibliothèques partagées
• cacher certains détails internes
• diminution des cycles de recompilation

Il peut s'agir ou non d'avantages réels pour vous. Pour ma part, je ne me soucie pas de quelques minutes de recompilation. Les utilisateurs finaux ne s'en soucient généralement pas non plus, car ils compilent toujours une fois et depuis le début.

Les inconvénients possibles sont (également ici, en fonction de l'implémentation et s'il s'agit d'inconvénients réels pour vous) :

• Augmentation de l'utilisation de la mémoire en raison d'un plus grand nombre d'allocations qu'avec la variante naïve.
• effort de maintenance accru (vous devez écrire au moins les fonctions de transfert)
• perte de performance (le compilateur peut ne pas être capable d'inliner des choses comme il le fait avec une implémentation naïve de votre classe)

Donnez donc soigneusement une valeur à chaque chose, et évaluez-la par vous-même. Pour moi, il s'avère presque toujours que l'utilisation de l'idiome PIMPL ne vaut pas la peine. Il n'y a qu'un seul cas où je l'utilise personnellement (ou du moins quelque chose de similaire) :

Mon enveloppe C++ pour le système Linux stat appel. Ici, la structure de l'en-tête C peut être différente, en fonction de ce que l'on veut faire. #defines sont définis. Et comme l'en-tête de mon wrapper ne peut pas tous les contrôler, j'ai seulement #include <sys/stat.h> dans mon .cxx et éviter ces problèmes.

Answer 3

Je suis d'accord avec tous les autres au sujet des marchandises, mais permettez-moi de mettre en évidence une limite : ne fonctionne pas bien avec les modèles .

La raison en est que l'instanciation des modèles nécessite la déclaration complète disponible à l'endroit où l'instanciation a eu lieu. (Et c'est la raison principale pour laquelle vous ne voyez pas de méthodes de modèles définies dans des fichiers .cpp).

Vous pouvez toujours vous référer aux sous-classes modélisées, mais comme vous devez toutes les inclure, tous les avantages du "découplage de l'implémentation" lors de la compilation (éviter d'inclure tout le code spécifique à la plate-forme partout, raccourcir la compilation) sont perdus.

C'est un bon paradigme pour le classique OOP (basée sur l'héritage), mais pas pour la programmation générique (basée sur la spécialisation).

Answer 4

D'autres personnes ont déjà présenté les avantages et inconvénients techniques, mais je pense que les points suivants méritent d'être soulignés :

D'abord et avant tout, ne soyez pas dogmatique. Si PIMPL fonctionne dans votre situation, utilisez-le - ne l'utilisez pas simplement parce que "c'est mieux OO puisqu'il vraiment cache l'implémentation", etc. Citation de la FAQ C++ :

l'encapsulation est pour le code, pas pour les gens ( source )

Pour vous donner un exemple de logiciel open source, où il est utilisé et pourquoi : OpenThreads, la bibliothèque de threading utilisée par le OpenSceneGraph . L'idée principale est de supprimer de l'en-tête (par exemple, <Thread.h> ) tout le code spécifique à la plate-forme, car les variables d'état internes (par exemple, les gestionnaires de threads) diffèrent d'une plate-forme à l'autre. De cette façon, on peut compiler du code contre votre bibliothèque sans connaître les particularités des autres plateformes, car tout est caché.

Answer 5

Je considérerais principalement le PIMPL pour les classes exposées pour être utilisées comme une API par d'autres modules. Cela présente de nombreux avantages, car la recompilation des modifications apportées à l'implémentation PIMPL n'affecte pas le reste du projet. De plus, pour les classes API, elles favorisent une compatibilité binaire (les changements dans l'implémentation d'un module n'affectent pas les clients de ces modules, ils n'ont pas besoin d'être recompilés car la nouvelle implémentation a la même interface binaire - l'interface exposée par le PIMPL).

Quant à l'utilisation de PIMPL pour chaque classe, je serais prudent car tous ces avantages ont un coût : un niveau supplémentaire d'indirection est nécessaire pour accéder aux méthodes d'implémentation.