SOについては、pimplイディオムについていくつか質問がありますが、実際にどのくらいの頻度で活用されているかについては、もっと興味があります。
パフォーマンスとカプセル化の間にはいくつかのトレードオフがあることを理解しています。さらに、余分なリダイレクトによるデバッグの煩わしさもあります。
それで、これはクラスごとに採用されるべきものですか、それともオールオアナッシングベースですか？これはベストプラクティスですか、それとも個人的な好みですか？
それはやや主観的だと思いますので、私の最優先事項を挙げさせてください。
ある時点でコードをライブラリとして公開する必要があると常に想定しているので、それも考慮事項です。
編集：同じことを達成するための他のオプションは歓迎すべき提案です。
pImpl は、r 値セマンティクスがある場合に最適に機能します。
実装の詳細を隠すこともできる pImpl の「代替」は、抽象基本クラスを使用し、派生クラスに実装を配置することです。ユーザーは、ある種の「ファクトリ」メソッドを呼び出してインスタンスを作成し、通常は抽象クラスへのポインター (おそらく共有ポインター) を使用します。
代わりに、pImpl の背後にある理論的根拠は次のとおりです。
pImpl のコンテナー クラスのセマンティクスは次のようになります。したがって、Impl* ではなく shared_ptr があります
クラスがデストラクタの時点で完全である限り、shared_ptr を使用して前方宣言を使用できます。デフォルトの場合でも、デストラクタを定義する必要があります（おそらくそうなります）。
交換可能。「空かもしれない」を実装し、「スワップ」を実装できます。ユーザーは、1 つのインスタンスを作成し、それに非 const 参照を渡して、「スワップ」を使用してデータを取り込むことができます。
2段階施工。空のものを作成し、それに対して「load()」を呼び出してデータを取り込みます。
shared は、r 値のセマンティクスがなくても、少しでも好みがある唯一のものです。それらを使用して、コピー不可、割り当て不可を適切に実装することもできます。私は、関数を呼び出すことができるのが好きです。
ただし、実装が 1 つしかない場合でも、pImpl よりも抽象基本クラスを使用する傾向が強いことがわかりました。