Deleter type in unique_ptr vs. shared_ptr

Question

標準でstd::unique_ptrとstd::shared_ptrという2つの全く異なる方法でポインタが所有している可能性があることが判明したとき、私は非常に興味があると思った。ここでcppreference::unique_ptrとcppreference::shared_ptrからの宣言は次のとおりです。

template< 
    class T, 
    class Deleter = std::default_delete<T> 
> class unique_ptr; 

template< class T > class shared_ptr; 

あなたがunique_ptrをを見ることができるようにテンプレート引数としてDELETER・オブジェクトのタイプを「節約」。また、これはDELETERが後で上のポインタから取得された方法で見ることができます。

// unique_ptr has a member function to retrieve the Deleter 
template< 
    class T, 
    class Deleter = std::default_delete<T> 
> 
Deleter& unique_ptr<T, Deleter>::get_deleter(); 

// For shared_ptr this is not a member function 
template<class Deleter, class T> 
Deleter* get_deleter(const std::shared_ptr<T>& p); 

誰かがこの違いの後ろに合理的に説明できますか？私は明らかにunique_ptrのコンセプトを支持していますが、それはなぜshared_ptrにも適用されませんか？また、なぜ後者の場合、get_deleterが非メンバ関数になるのでしょうか？ここで

Answer 1

あなたはスマートポインタのためのオリジナルの提案を見つけることができます：http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1450.html

は、これはかなり正確にあなたの質問に答える：

デリータが壊れないアロケーション戦略を変更し、タイプの一部ではないので、ソースまたはバイナリの互換性があり、クライアントの再コンパイルは必要ありません。

std::shared_ptrのクライアントに、例えば異なるdeletersとshared_ptrインスタンスが同一の容器に保存することができ、いくつかのより多くの柔軟性を与えるので、これもまた有用です。

shared_ptrの実装では、（参照カウントを格納するために）共有メモリブロックが必要となるため、未処理のポインタに比べていくらかのオーバーヘッドが必要であるため、タイプ消去されたデリータを追加することは大きな問題ではありませんここに。一方、オーバーヘッドが全くなく、すべてのインスタンスがデリゲータを組み込む必要があるので、それを型の一部にするのは自然なことです。