私が理解しているようにmake_shared<T>(...)、メモリ割り当ての最適化を提供する場合があります（クラスTのインスタンスと同じメモリブロック内に参照カウンターを割り当てる場合があります）。
enable_shared_from_this は同じ最適化を提供しますか? そう：
class T : std::enable_shared_from_this<T> {};
...
auto t = std::shared_ptr<T>(new T);
以下と同じです:
class T {};
...
auto t = std::make_shared<T>();
sizeof(T) を考慮しない場合。
enable_shared_from_this は同じ最適化を提供しますか? そう：
いいえ。標準の文言からわかるようにenable_shared_from_this<T>、weak_ptr<T>データ メンバーがあります。weak_ptr<T>これにより、参照カウントを含む制御ブロックへのポインターを持つクラスにa が追加されます。参照カウントは直接含まれていません。参照カウントを含む制御ブロックは、オブジェクトの外部にまだ存在します。
参照カウントを含む制御ブロックは、オブジェクトweak_ptrを参照していた他のオブジェクトが引き続き制御ブロックにアクセスして期限切れかどうかを確認できるように、オブジェクトよりも長く存続する必要があります。
制御ブロックがオブジェクト内にある場合、オブジェクトが破棄されたときに破棄され、weak_ptrオブジェクトが期限切れかどうかをダングリングが安全に判断することはできません。理論的には、制御ブロックのメモリは割り当てられたままで使用され、参照カウントは更新されますが、それらが含まれていたオブジェクトが破棄されたとしても、それはかなり醜いようです (そして、オブジェクトが , で破棄されないことを意味しますdelete)。メモリを解放するには、明示的なデストラクタ呼び出しと明示的な呼び出しが必要にoperator deleteなります)。
shared_ptr また、所有がカスタム デリーターまたはカスタム アロケーターで作成された場合、これらのオブジェクトのサイズが事前にわからないため、埋め込み制御ブロックを使用できませんでした。このような場合、基本クラスに埋め込まれたものに加えてenable_shared_from_this<T>外部制御ブロックを割り当てる必要があり、さらに多くのスペースを浪費します。