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?
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 ofshared_ptr<T>
;)As such,
enable_shared_from_this
must be accessible by any code in order for theshared_ptr
constructor to work.