私はHerb Sutterの「Exceptional C ++」という本を読んでいます。その本で、pImplイディオムについて学びました。基本的には、のprivateオブジェクトの構造を作成し、classそれらを動的に割り当てて、コンパイル時間を短縮します（また、プライベート実装をより適切に非表示にする）。

例えば：

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

次のように変更できます：

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

CPPでの定義：

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

これはかなり興味深いようですが、これまでこの種のアプローチを見たことがありません。これまでに取り組んだ企業や、ソースコードを見たオープンソースプロジェクトでも見たことがありません。それで、このテクニックが実際に実際に使用されているのだろうか？

どこでも使用できますか、それとも注意して使用しますか？また、この手法は、パフォーマンスが非常に重要な組み込みシステムでの使用をお勧めしますか？

それで、このテクニックが実際に実際に使用されているのだろうか？どこでも使用できますか、それとも注意して使用しますか？

もちろん使用しています。私のプロジェクトでは、ほとんどすべてのクラスで使用しています。

PIMPLイディオムを使用する理由：

バイナリ互換性

ライブラリを開発しているときXImpl、クライアントとのバイナリ互換性を壊すことなくフィールドを追加/変更できます（これはクラッシュを意味します！）。Xクラスに新しいフィールドを追加しても、クラスのバイナリレイアウトは変更されないためXimpl、マイナーバージョンの更新でライブラリに新しい機能を追加しても安全です。

もちろん、バイナリの互換性を損なうことなく、新しいパブリック/プライベート非仮想メソッドをX/に追加することもできますがXImpl、これは標準のヘッダー/実装手法と同等です。

データ非表示

ライブラリ、特にプロプライエタリなライブラリを開発している場合は、ライブラリのパブリックインターフェイスを実装するために使用された他のライブラリ/実装手法を開示しないことが望ましい場合があります。知的所有権の問題のためか、ユーザーが実装について危険な仮定をしたり、ひどいキャストトリックを使用してカプセル化を壊したりする可能性があると考えているためです。PIMPLはそれを解決/軽減します。

コンパイル時間

XフィールドまたはメソッドXImpl（あるいはその両方）をクラスに追加/削除するときに、標準の手法でプライベートフィールド/メソッドの追加にマップするときに、ソース（実装）ファイルのみを再構築する必要があるため、コンパイル時間が短縮されます。実際には、これは一般的な操作です。

標準ヘッダー/実装技術（PIMPLを使用しない）では、新しいフィールドをに追加すると、割り当てのサイズを調整する必要があるため、（スタックまたはヒープのいずれかで）X割り当てるすべてのクライアントをX再コンパイルする必要があります。まあ、Xを割り当てないすべてのクライアントも再コンパイルする必要がありますが、それはオーバーヘッドです（クライアント側の結果のコードは同じになります）。

さらに、カプセル化の理由でこのメソッドを呼び出すことができない場合でもXClient1.cpp、プライベートメソッドX::foo()が追加XおよびX.h変更された場合でも、標準のヘッダーと実装の分離を再コンパイルする必要がXClient1.cppあります。上記のように、これは純粋なオーバーヘッドであり、実際のC ++ビルドシステムの動作に関連しています。

もちろん、メソッドの実装を変更するだけの場合（ヘッダーに触れないため）再コンパイルは必要ありませんが、標準のヘッダー/実装手法と同等です。

この手法は、（パフォーマンスが非常に重要な）組み込みシステムでの使用をお勧めしますか？

それはあなたのターゲットがどれほど強力であるかに依存します。ただし、この質問への唯一の答えは、次のとおりです。あなたが得るものと失うものを測定および評価します。また、クライアントが組み込みシステムで使用するためのライブラリを公開していない場合は、コンパイル時の利点のみが適用されることを考慮してください。

少なくとも一部のバージョンでは、多くのライブラリがAPIを安定させるためにそれを使用しているようです。

しかし、すべてのものに関して、あなたは注意せずにどこでも何も使用するべきではありません。それを使用する前に常に考えます。それがあなたに与える利点を評価し、それらがあなたが支払う価格の価値があるかどうかを評価します。

それがあなたに与えるかもしれない利点は：

• 共有ライブラリのバイナリ互換性を維持するのに役立ちます
• 特定の内部の詳細を隠す
• 再コンパイルサイクルの減少

それらはあなたにとって本当の利点かもしれませんし、そうでないかもしれません。私と同じように、私は数分の再コンパイル時間を気にしません。エンドユーザーは通常、一度も最初からコンパイルするので、通常は行いません。

考えられる欠点は次のとおりです（ここでも、実装、およびそれらが実際の欠点であるかどうかによって異なります）。

• 単純なバリアントよりも多くの割り当てによるメモリ使用量の増加
• メンテナンス作業の増加（少なくとも転送機能を作成する必要があります）
• パフォーマンスの低下（クラスの単純な実装の場合とは異なり、コンパイラーはインライン化できない場合があります）

そのため、すべてに慎重に値を設定し、自分で評価してください。私にとって、ほとんどの場合、pimplイディオムを使用することは努力に値しないことがわかります。私がそれを個人的に使用するケースは1つだけです（または少なくとも同様のもの）。

Linux stat呼び出し用のC ++ラッパー。ここで、Cヘッダーの構造体は、#defines設定内容に応じて異なる場合があります。そして、私のラッパーヘッダーはそれらのすべてを制御することはできないので、私#include <sys/stat.h>は自分の.cxxファイルでのみこれらの問題を回避しています。

商品については他のすべての意見に同意しますが、証拠を提示しておきます。テンプレートではうまく機能しません。

その理由は、テンプレートのインスタンス化には、インスタンス化が行われた場所で利用可能な完全な宣言が必要だからです。（そして、それがCPPファイルに定義されたテンプレートメソッドが表示されない主な理由です）

テンプル化されたサブクラスを参照することはできますが、それらすべてを含める必要があるため、コンパイルにおける「実装デカップリング」（すべてのプラットフォーム固有のコードをすべての場所に含めることを避け、コンパイルを短縮する）の利点はすべて失われます。

古典的なOOP（継承ベース）には良いパラダイムですが、一般的なプログラミング（専門化ベース）には適していません。

他の人々はすでに技術的なメリット/デメリットを提供していますが、以下は注目に値すると思います：

何よりもまず、独断的ではありません。pImplがあなたの状況で機能する場合、それを使用してください-「それは本当に実装を隠しているのでそれは OOの方が良い」などという理由だけでそれを使用しないでください。C++ FAQの引用：

カプセル化は、人ではなくコード用です（ソース）

使用するオープンソースソフトウェアの例とその理由を説明するために、OpenSceneGraphで使用されるスレッドライブラリであるOpenThreadsについて説明します。<Thread.h>内部状態変数（スレッドハンドルなど）はプラットフォームごとに異なるため、主なアイデアは、ヘッダー（たとえば）からすべてのプラットフォーム固有のコードを削除することです。この方法では、すべてが隠されているため、他のプラットフォームの特異性を知らなくても、ライブラリに対してコードをコンパイルできます。

他のモジュールがAPIとして使用するために公開されているクラスのPIMPLを主に検討します。これには、PIMPL実装で行われた変更の再コンパイルがプロジェクトの他の部分に影響を与えないため、多くの利点があります。また、APIクラスの場合、バイナリ互換性を促進します（モジュール実装の変更はそれらのモジュールのクライアントに影響を与えません。新しい実装が同じバイナリインターフェイス（PIMPLによって公開されるインターフェイス）を持っているため、再コンパイルする必要はありません）。

すべてのクラスでPIMPLを使用する場合は、これらの利点がすべて犠牲になるため、注意が必要です。実装メソッドにアクセスするには、追加のレベルの間接参照が必要です。

これはデカップリングの最も基本的なツールの1つだと思います。

埋め込みプロジェクト（SetTopBox）でpimpl（およびExceptional C ++の他の多くのイディオム）を使用していました。

このイディムのプロジェクトでの特別な目的は、XImplクラスが使用するタイプを非表示にすることでした。具体的には、これを使用して、さまざまなヘッダーがプルされるさまざまなハードウェアの実装の詳細を非表示にしました。あるプラットフォームと別のプラットフォームでは、XImplクラスの実装が異なりました。クラスXのレイアウトは、プラットフォームに関係なく同じままでした。

以前はこのテクニックをよく使用していましたが、その後、このテクニックから遠ざかっていました。

もちろん、実装の詳細をクラスのユーザーから隠すことは良い考えです。ただし、クラスのユーザーに抽象インターフェースを使用させ、実装の詳細を具象クラスにすることで、これを行うこともできます。

pImplの利点は次のとおりです。

1. このインターフェースの実装が1つしかないと仮定すると、抽象クラス/具象実装を使用しない方が明確です。

2. 複数のクラスが同じ「impl」にアクセスするようなクラスのスイート（モジュール）があるが、モジュールのユーザーは「公開された」クラスのみを使用する場合。

3. これが悪いことだと思われる場合は、vテーブルはありません。

私が見つけたpImplの欠点（抽象インターフェースがよりうまく機能する場合）

1. 「プロダクション」実装は1つしかないかもしれませんが、抽象インターフェースを使用することで、単体テストで機能する「模擬」実装を作成することもできます。

2. （最大の問題）。unique_ptrと移動の時代の前は、pImplを保存する方法に関して選択の制限がありました。生のポインタとあなたのクラスがコピー不可能であるという問題がありました。古いauto_ptrは、順方向に宣言されたクラスでは機能しません（とにかくすべてのコンパイラでは機能しません）。したがって、人々はクラスをコピー可能にするのに優れたshared_ptrの使用を開始しましたが、もちろん両方のコピーの基になるshared_ptrは同じではなく、予想外の可能性があります（一方を変更すると、両方が変更されます）。そのため、解決策は、多くの場合、内部ポインターに未加工のポインターを使用し、クラスをコピー不可にして、代わりにshared_ptrを返すことでした。したがって、newへの2つの呼び出し。（実際には、3つの古いshared_ptrが2番目のものを提供します）。

3. constnessはメンバーポインターに伝達されないため、技術的には実際にはconst-correctではありません。

そのため、一般的に私は長年、pImplから抽象インターフェースの使用法（およびインスタンスを作成するファクトリメソッド）に移行してきました。

他の多くの人が言ったように、Pimplイディオムは、残念ながらパフォーマンスの損失（追加のポインターの間接化）と追加のメモリーの必要性（メンバーポインター自体）により、完全な情報の非表示とコンパイルの独立性に到達できます。組み込みソフトウェアの開発、特にメモリを可能な限り節約する必要があるシナリオでは、追加のコストが重要になる可能性があります。C ++抽象クラスをインターフェイスとして使用すると、同じコストで同じ利点が得られます。これは実際にはC ++の大きな欠点を示しています。Cのようなインターフェイス（パラメーターとして不透明なポインターを使用するグローバルメソッド）を繰り返さないと、追加のリソースの欠点がなければ、真の情報の非表示とコンパイルの独立性を保つことができません。これは主に、ユーザーによるインクルードが必要なクラスの宣言、

これは私が遭遇した実際のシナリオで、このイディオムは非常に役立ちました。私は最近、ゲームエンジンでDirectX 11と既存のDirectX 9サポートをサポートすることを決定しました。エンジンはすでにほとんどのDX機能をラップしているため、DXインターフェイスは直接使用されませんでした。それらはヘッダーでプライベートメンバーとして定義されただけです。エンジンはDLLを拡張機能として利用し、キーボード、マウス、ジョイスティック、スクリプトのサポートを、他の多くの拡張機能と同じように追加します。これらのDLLのほとんどはDXを直接使用しませんでしたが、DXを公開するヘッダーをプルしただけなので、知識とDXへのリンクが必要でした。DX 11を追加すると、この複雑さは劇的に増加しますが、不必要です。ソースでのみ定義されたPimplにDXメンバーを移動すると、この面倒がなくなりました。このライブラリの依存関係の削減に加えて、

多くのプロジェクトで実際に使用されています。その有用性はプロジェクトの種類に大きく依存します。これを使用した最も顕著なプロジェクトの1つはQtです。基本的な考え方は、実装またはプラットフォーム固有のコードをユーザー（Qtを使用する他の開発者）から隠すことです。

これは高貴なアイデアですが、これには本当の欠点があります。デバッグプライベートな実装に隠されたコードが高品質である限り、これで十分ですが、そこにバグがある場合、ユーザー/開発者に問題があります。なぜなら、たとえ彼が実装のソースコードを持っているとしても、それは隠された実装への単なるばかげたポインタだからです。

したがって、ほとんどすべての設計決定と同様に、賛否両論があります。

私が見ることができる1つの利点は、プログラマが特定の操作をかなり高速に実装できることです。

X( X && move_semantics_are_cool ) : pImpl(NULL) {
    this->swap(move_semantics_are_cool);
}
X& swap( X& rhs ) {
    std::swap( pImpl, rhs.pImpl );
    return *this;
}
X& operator=( X && move_semantics_are_cool ) {
    return this->swap(move_semantics_are_cool);
}
X& operator=( const X& rhs ) {
    X temporary_copy(rhs);
    return this->swap(temporary_copy);
}

PS：移動のセマンティクスを誤解していないことを願っています。