It's common to inherit from enable_shared_from_this just to be able to return shared_ptr's from member functions as the primary intention, with no intention of exposing enable_shared_from_this API in the derived class.
Since to make use of enable_shared_from_this one must do so through public inheritance (does the standard mandates this? what's the rationale?), this can't be achieved and enable_shared_from_this API is forced into derived class public API.
Inherenting enable_shared_from_this privately and making shared_ptr a friend class do work on clang coupled with libc++, but doesn't work with stdlibc++.
Since private enable_shared_from_this + friend shared_ptr (or protected inheritance) seems to cover this use case, shouldn't it be sufficient by the standard for fitting as a solution for the "shared from this" problem?
Since
private enable_shared_from_this+ friendshared_ptrseems to cover this use case, shouldn't it be sufficient by the standard?
No. The standard permits implementations wide latitude with how they implement things. The constructor of shared_ptr<T> that adopts an object may defer the shared-from-this stuff to some helper function or other object. For maximum irony, it could defer to a base class of shared_ptr<T> ;)
As such, enable_shared_from_this must be accessible by any code in order for the shared_ptr constructor to work.
来源：https://stackoverflow.com/questions/38165889/does-the-standard-mandate-enable-shared-from-this-is-to-be-inherited-publicly-w