5

そこで、PIMPL とスタック割り当てについて考えてみました。私はライブラリを作成しており、PIMPL を使用してクラスのプライベート メンバーを非表示にすることにしました。つまり、このようにクラスを宣言することになります

class Foo {
private:
    class Handle;
    std::tr1::shared_ptr<Handle> handle;
public:
    Foo();
};

それはかなり簡単です。しかし、コンストラクターでこれを行います

Foo::Foo() : handle(new Handle()) {}

したがって、誰かが私のライブラリを使用してスタックに Foo を作成する場合、基本的にヒープ割り当てを行っています。これは、PIMPL を使用する際に考慮しなければならないトレードオフですか? コンストラクターの横に警告を表示してドキュメントをリリースすることを考えました:「警告: これにより、ヒープ割り当てが発生します」など。

私のもう 1 つの考えは、純粋な仮想インターフェイスとして実装に公開されるすべてのクラスと、スマート ポインターを返す一連の静的ファクトリ メソッドを用意することでした。これはヒープ割り当ても意味しますが、トリックはありません。

何か考えや提案はありますか？ライブラリを使用するプログラマーに対して、私は過度に配慮していませんか?

4

2 に答える 2

4

これは、PIMPL を使用する際に考慮しなければならないトレードオフですか?

事実上、そうですが、「The Fast Pimpl Idiom」で Herb Sutter によって説明されているような手法はありますが、ヒープ割り当てを排除または高速化するために使用できますが、複雑さが増します。

コンストラクターの横に警告を表示してドキュメントをリリースすることを考えました:「警告: これにより、ヒープ割り当てが発生します」など。

そうする必要がある場合のみ (つまり、クラスがヒープ割り当てを実行したという事実にユーザーが驚かれる場合のみ)。多くのクラスは、C++ 標準ライブラリ (たとえば、すべてのコンテナー) の多くを含め、ヒープ割り当てを実行します。

ライブラリを使用するプログラマーに対して、私は過度に配慮していませんか?

おそらく:-)。クラスに高いパフォーマンスが必要な場合や、クラスのインスタンスが非常に頻繁に作成および破棄されることが予想される場合を除き、あまり心配する必要はありません。もちろん、重要なパフォーマンス要件がある場合、pimpl は適切な選択ではない可能性があります。

于 2010-07-11T02:37:47.343 に答える
4

したがって、誰かが私のライブラリを使用してスタックに Foo を作成する場合、基本的にヒープ割り当てを行っています。これは、PIMPL を使用する際に考慮しなければならないトレードオフですか?

うん。

コンストラクターの横に警告を表示してドキュメントをリリースすることを考えました:「警告: これにより、ヒープ割り当てが発生します」など。

私はそれを過度に積極的なコメントと考えています:)クラスのパフォーマンスが非常に重要な場合は、おそらくPIMPLイディオムを避ける必要があります。数字を表している場合、これは懸念事項であり、注目に値する可能性があります。データベース接続の実装を隠している場合、コメントする価値はありません:)

私のもう 1 つの考えは、純粋な仮想インターフェイスとして実装に公開されるすべてのクラスと、スマート ポインターを返す一連の静的ファクトリ メソッドを用意することでした。これはヒープ割り当ても意味しますが、トリックはありません。

ええ、それはユーザーにとってもう少し明白ですが、おそらくあなた自身について心配する価値はありません.

何か考えや提案はありますか？ライブラリを使用するプログラマーに対して、私は過度に配慮していませんか?

トレードオフがありますが、クラスが pimpl イディオムから実際に得るのに十分なほど複雑である場合、おそらくヒープ割り当ては問題ないと見なすことができます。私があなたのライブラリを使用していたとしても、おそらく私には関係ないでしょう。

于 2010-07-11T02:42:44.970 に答える