enable_shared_from_this 帮助器包含一个弱指针，该指针在创建指向对象的共享指针时设置。这意味着在对象中存在引用计数（使用make_shared 单独或与对象一起分配）和额外的weak_ptr。
现在为什么不简单地包含引用计数呢？当从哑指针设置shared_ptr时，类型必须完全定义，所以shared_ptr构造函数或赋值运算符可以检测到类型是从enable_shared_from_this派生的并使用正确的计数器并且格式可以保持不变，所以复制不在乎。事实上，shared_ptr 已经检测到它来设置嵌入的weak_ptr。
【问题讨论】：
标签： c++ c++11 shared-ptr enable-shared-from-this
首先想到的是这种方法是否可行，答案是不可行：
struct X : enable_shared_from_this {};
std::shared_ptr<X> p( new X );
std::weak_ptr<X> w( p );
p.reset(); // this deletes the object
if ( w.use_count() ) { // this needs access to the count object
// but it is gone! Undefined Behavior
如果计数存储在对象中，则没有weak_ptr 可以超过对象，这违反了合同。 weak_ptr 的整个想法是它们可以比对象更长寿（如果最后一个 shared_ptr 超出范围，即使有 weak_ptr，对象也会被删除）
【讨论】：
weak_ptr 存储在哪里，都有一段共享数据：对象是否存在，该数据在count 对象中，并且在最后一个 weak_ptr 超出范围/被删除之前无法删除。请注意，weak_ptr 在对象死亡时不被释放，它们可以比指向对象的寿命更长（整个目的是它们可以）。我不认为多线程与这个问题有任何关系。
enable_shared_from_this 中。另一方面，优点是连续分配，这已经可以通过使用make_shared 来实现（单个分配，两个对象：引用计数/真实对象）。
关注点分离：make_shared 用于嵌入计数，enable_shared_from_this 用于shared_from_this。
没有理由将两者混为一谈：库不能假设客户端代码有什么需求。通过将两者分开，客户端代码可以挑选最适合的代码。
此外 Boost（shared_ptr 来自哪里）还提出了intrusive_ptr。
（考虑到您的建议似乎不允许自定义删除器。您可以通过将enable_shared_from_this 更改为template<typename T, typename Deleter = default_deleter<T>> class enable_shared_from_this; 来解决此问题，但此时它已接近于重新发明intrusive_ptr .)
【讨论】：
enable_shared_from_this 嵌入了计数，它会节省空间，所以效率会更高。关注点分离不是以较低效率的方式实施它的理由。而且我认为它不会阻止自定义删除器以正常方式传递（shared_ptr 构造函数只需要稍微不同地包装它，因为它不应该删除引用计数）。
shared_ptr<enabled_type>(new enabled_type, some_deleter())，您的方案完成了多少次分配？如果删除器是单独分配的，那么引用计数是嵌入到对象中还是与删除器一起存在真的很重要吗？
make_shared 确实设置了一些限制（即没有自定义删除器），这不是一种适用于每种情况的优化。就像你建议的那样。
shared_ptr 的实现，但我希望它在删除器上执行类型擦除，这意味着类型擦除的对象将是相同的计数对象。
要从将计数嵌入对象中获得任何优势，您需要
取消shared_ptr 中的第二个指针，这将
改变它的布局，也给创建析构函数带来了问题
目的。如果更改布局，则此更改必须可见
在任何地方都使用shared_ptr。这意味着你不能拥有
shared_ptr 的实例指向不完整的类型。
【讨论】：
shared_ptr 可以在寄存器中传递，而带有两个指针的shared_ptr 则不会。这将产生根本性的不同。更一般地说，复制两个指针会比复制一个指针花费更多。但是你是对的，分配是昂贵的，另一个重要的问题是局部性——一个单独的计数器可能在不同的缓存行中，这会增加缓存命中。因此，即使使用第二个指针，您也可以获得很多。
boost::shared_ptr 那样分配单独的计数器析构函数。