来自 http://en.cppreference.com/w/cpp/memory/unique_ptr:
如果
T是某个基类B的派生类，则std::unique_ptr<T>隐式转换为std::unique_ptr<B>。结果的std::unique_ptr<B>的默认删除器将使用B的 operator delete，这会导致未定义行为，除非B的析构函数是虚拟的。请注意，std::shared_ptr的行为不同:std::shared_ptr<B>将使用类型T的 operator delete，即使B的析构函数不是虚拟的，它也能正确删除所拥有的对象。
上述描述中，在销毁时行为差异的原理是什么？我最初的猜测是性能方面的问题？
另外有趣的是如何在 B 的析构函数不是虚拟的情况下，std::shared_ptr<B> 能够调用类型 T 的析构函数？
std::shared_ptr<X>相对于原始的B*有一些额外的开销。
shared_ptr<X>基本上维护4个东西。它维护一个指向B的指针，它维护两个引用计数（一个是“硬”引用计数，另一个是weak_ptr的“软”引用计数），以及它维护一个清理函数。
清理函数是shared_ptr<X>行为不同的原因。当您创建一个shared_ptr<X>时，会创建一个调用该特定类型析构函数的函数，并将其存储在由shared_ptr<X>管理的清理函数中。
当您更改所管理的类型（B*变为C*）时，清理函数保持不变。
因为shared_ptr<X>需要管理引用计数，所以清理函数存储的额外开销是微不足道的。
对于unique_ptr<B>，该类几乎与原始的B*一样便宜。它除了B*之外没有任何状态，并且其行为（在销毁时）归结为if (b) delete b;。（是的，那个if (b)是多余的，但优化器可以找出来）。
为了支持向基类转换和作为派生类删除，必须存储额外的状态，以记住unique_ptr实际上是一个派生类。这可以采用存储指向删除器的指针的形式，例如shared_ptr。
然而，这将使unique_ptr<B>的大小翻倍，或者需要在堆上存储数据。
决定让unique_ptr<B>没有开销，因此它不支持向基类转换并调用基类的析构函数。
现在，您可能可以通过添加删除器类型并存储知道正在销毁的东西类型的销毁函数来教会unique_ptr<B>执行此操作。上述内容讨论了unique_ptr的默认删除器，该删除器是无状态且微不足道的。
struct deleter {
void* state;
void(*f)(void*);
void operator()(void*)const{if (f) f(state);}
deleter(deleter const&)=default;
deleter(deleter&&o):deleter(o) { o.state = nullptr; o.f=nullptr; }
deleter()=delete;
template<class T>
deleter(T*t):
state(t),
f([](void*p){delete static_cast<T*>(p);})
{}
};
template<class T>
using smart_unique_ptr = std::unique_ptr<T, deleter>;
template<class T, class...Args>
smart_unique_ptr<T> make_smart_unique( Args&&... args ) {
T* t = new T(std::forward<Args>(args)...);
return { t, t };
}
void(*)(void*) deleter可能会遇到问题，因为传递的void*在基类和派生类之间的值可能会有所不同。unique_ptr并不真正具有零开销。它也必须存储一个deleter。不像shared_ptr，尽管通过模板参数，deleter类型是其类型的一部分。对于零大小的deleter，可以通过空基类优化实现真正的零开销。 - Angew is no longer proud of SOunique_ptr有更多的开销。 - Yakk - Adam Nevraumontif(b) 部分对于无法处理 null 值的自定义删除器非常重要。此外，std::function 是一个糟糕的删除器 - 它的构造函数可能会抛出异常。 - T.C.