为什么shared_ptr<void>合法，而unique_ptr却格式<void>不正确？

Question

这个问题真的很适合标题:我很想知道这种差异的技术原因是什么，以及基本原理是什么?

std::shared_ptr<void> sharedToVoid; // legal;
std::unique_ptr<void> uniqueToVoid; // ill-formed;

Answer 1

这是因为std::shared_ptr实现了类型擦除，而std::unique_ptr没有。

---

由于std::shared_ptr实现了类型擦除，它还支持另一个有趣的属性，即不需要删除器的类型作为类模板的模板类型参数。看看它们的声明:

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

以Deleter为类型参数，而

template<class T> 
class shared_ptr;

没有。

那么，为什么shared_ptr实现类型擦除?

确实是这样做的，因为它必须支持引用计数，为了支持这一点，它必须从堆中分配内存，因为它无论如何都必须分配内存，所以它更进一步实现了类型擦除——这也需要堆分配。所以基本上这就是机会主义!

由于类型擦除，std::shared_ptr能够支持两件事:

• 它可以将任何类型的对象存储为void*， ，但是它仍然能够通过正确地调用它们的析构函数来正确地删除。
• 删除器的类型没有作为类型参数传递给类模板，这意味着在不影响类型安全的情况下有一点自由。

好吧。以上就是std::shared_ptr的工作原理。

现在的问题是，std::unique_ptr可以存储对象作为 void*吗?那么，答案是可以——只要您传递一个合适的删除器作为参数。下面就是这样一个演示:

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

---

你在评论中问了一个非常有趣的问题:

在我的例子中，我将需要一个类型擦除删除器，但这似乎也是可能的(以一些堆分配为代价)。基本上，这是否意味着实际上存在第三种类型的智能指针的利基位置:具有类型擦除的独占所有权智能指针。

@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.

Answer 2

其中一个基本原理是shared_ptr的许多用例之一—即作为生命周期指示器或哨兵。

这在最初的boost文档中提到过:

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是同步操作