为什么unique_ptr <void>格式错误，但shared_ptr <void>合法？

这个问题确实符合标题：我很好奇，知道造成这种差异的技术原因是什么，但也有理由吗？

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

这是因为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*，但是仍然可以通过正确调用其析构函数来正确删除销毁的对象。
• deleter的类型不会作为类型参数传递给类模板，这意味着在不影响type-safety的情况下具有一点自由度。

好的。这就是如何std::shared_ptr工作的全部。

现在的问题是，可以std::unique_ptr将对象存储为 void*吗？好吧，答案是肯定的，只要您传递一个合适的Deleter作为参数即可。这是一个这样的演示：

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杰索普提出了以下解决方案，

我从未真正尝试过此操作，但是也许您可以通过将适当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.

希望能有所帮助。

基本原理之一是在a的许多用例之一中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是同步操作。