Je vois beaucoup de code source qui utilise l'idiome PImpl en C ++. Je suppose que son objectif est de masquer les données / types / implémentations privées, de manière à pouvoir supprimer la dépendance, puis à réduire le temps de compilation et le problème d'inclusion d'en-tête.
Mais les classes d’interface / pure-abstract en C ++ ont également cette capacité, elles peuvent également être utilisées pour masquer des données / type / implémentation. Et pour que l'appelant ne voie que l'interface lors de la création d'un objet, nous pouvons déclarer une méthode factory dans l'en-tête de l'interface.
La comparaison est:
Coût :
Le coût de l'interface est moins élevé, car vous n'avez même pas besoin de répéter l'implémentation de la fonction wrapper publique
void Bar::doWork() { return m_impl->doWork(); }, il vous suffit de définir la signature dans l'interface.Bien compris :
La technologie d'interface est mieux comprise par tous les développeurs C ++.
Performance :
Les performances de l'interface ne sont pas pires que l'idiome PImpl, un accès supplémentaire à la mémoire. Je suppose que la performance est la même.
Voici le pseudocode pour illustrer ma question:
// Forward declaration can help you avoid include BarImpl header, and those included in BarImpl header.
class BarImpl;
class Bar
{
public:
// public functions
void doWork();
private:
// You don't need to compile Bar.cpp after changing the implementation in BarImpl.cpp
BarImpl* m_impl;
};
Le même objectif peut être mis en œuvre à l'aide de l'interface:
// Bar.h
class IBar
{
public:
virtual ~IBar(){}
// public functions
virtual void doWork() = 0;
};
// to only expose the interface instead of class name to caller
IBar* createObject();
Alors, quel est l'intérêt de PImpl?
Implclasse ne cassera pas leABI, mais ajouter une fonction publique dans une interface casseraABI.