web-dev-qa-db-ja.com

unique_ptr <void>の形式が正しくないのに、shared_ptr <void>が正当なのはなぜですか？

質問はタイトルに本当に当てはまります。この違いの技術的な理由は何かを知りたいのですが、その根拠も知りたいですか？

std::shared_ptr<void> sharedToVoid; // legal;
std::unique_ptr<void> uniqueToVoid; // ill-formed;
c++shared-ptrsmart-pointersunique-ptr
89
Ad N

std::shared_ptrが型消去を実装するのに対し、std::unique_ptrは実装しないためです。

std::shared_ptrは型消去を実装しているため、別の興味深いプロパティ、つまりnot削除者の型が必要テンプレート型引数としてクラステンプレートにを必要とします。彼らの宣言を見てください：

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

型パラメーターとしてDeleterを持ちますが、

template<class T> 
class shared_ptr;

それを持っていません。

ここで問題は、なぜshared_ptrが型消去を実装するのかということです。参照カウントをサポートする必要があり、これをサポートするために、ヒープからメモリを割り当てる必要があり、メモリを割り当てる必要があるため、さらに一歩進んで型消去を実装する必要があります—ヒープの割り当ても必要なので、基本的には日和見主義者です！

型の消去により、std::shared_ptrは次の2つのことをサポートできます。

  • 任意のタイプのオブジェクトをvoid*、として保存できますが、破壊時にオブジェクトを適切に削除できます正しくデストラクターを呼び出します。
  • 削除者のタイプは、クラステンプレートへのタイプ引数として渡されません。これは、タイプの安全性を損なうことなく、少しの自由を意味します。

わかった。それがstd::shared_ptrの仕組みに関するすべてです。

質問は、std::unique_ptrオブジェクトを保存することはできますかasvoid*？さて、答えはyesです—適切な削除プログラムを引数として渡せば。そのようなデモの1つを次に示します。

int main()
{
    auto deleter = [](void const * data ) {
        int const * p = static_cast<int const*>(data);
        std::cout << *p << " located at " << p <<  " is being deleted";
        delete p;
    };

    std::unique_ptr<void, decltype(deleter)> p(new int(959), deleter);

} //p will be deleted here, both p ;-)

出力（ オンラインデモ ）：

959 located at 0x18aec20 is being deleted

コメントで非常に興味深い質問をしました：

私の場合、型消去削除プログラムが必要になりますが、同様に可能です（ヒープ割り当てのコストがかかります）。基本的に、これは、スマートポインターの第3のタイプのニッチスポットがあることを意味します。つまり、タイプ消去を備えた排他的所有権のスマートポインターです。

@ Steve Jessop は次の解決策を提案しました。

私は実際にこれを試したことはありませんが、適切なstd::functionをunique_ptrの削除タイプとして使用することでそれを達成できるかもしれません。それが実際に動作すると仮定して、あなたは完了し、排他的所有権と型消去された削除者。

この提案に従って、これを実装しました（ただし、std::functionは必要ないと思われるため、使用しません）：

using unique_void_ptr = std::unique_ptr<void, void(*)(void const*)>;

template<typename T>
auto unique_void(T * ptr) -> unique_void_ptr
{
    return unique_void_ptr(ptr, [](void const * data) {
         T const * p = static_cast<T const*>(data);
         std::cout << "{" << *p << "} located at [" << p <<  "] is being deleted.\n";
         delete p;
    });
}

int main()
{
    auto p1 = unique_void(new int(959));
    auto p2 = unique_void(new double(595.5));
    auto p3 = unique_void(new std::string("Hello World"));
}

出力（ オンラインデモ ）：

{Hello World} located at [0x2364c60] is being deleted.
{595.5} located at [0x2364c40] is being deleted.
{959} located at [0x2364c20] is being deleted.

お役に立てば幸いです。

104
Nawaz

理論的根拠の1つは、shared_ptrの多くのユースケースの1つです。つまり、ライフタイムインジケータまたはセンチネルです。

これは、元のブーストドキュメントで言及されました。

auto register_callback(std::function<void()> closure, std::shared_ptr<void> pv)
{
    auto closure_target = { closure, std::weak_ptr<void>(pv) };
    ...
    // store the target somewhere, and later....
}

void call_closure(closure_target target)
{
    // test whether target of the closure still exists
    auto lock = target.sentinel.lock();
    if (lock) {
        // if so, call the closure
        target.closure();
    }
}

closure_targetは次のようなものです。

struct closure_target {
    std::function<void()> closure;
    std::weak_ptr<void> sentinel;
};

呼び出し元は、次のようなコールバックを登録します。

struct active_object : std::enable_shared_from_this<active_object>
{
    void start() {
      event_emitter_.register_callback([this] { this->on_callback(); }, 
                                       shared_from_this());
    }

    void on_callback()
    {
        // this is only ever called if we still exist 
    }
};

shared_ptr<X>は常にshared_ptr<void>に変換可能であるため、event_emitterはコールバックしているオブジェクトのタイプをまったく気付かずに認識できるようになりました。

この配置により、イベントエミッターのサブスクライバーが交差するケースを処理する義務を解放します（コールバックがキューに入れられ、active_objectが消える間にアクションを待つ場合はどうなりますか？）。また、サブスクリプションを同期解除する必要がないことも意味します。 weak_ptr<void>::lockは同期操作です。

7
Richard Hodges