问题
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?
回答1:
Since
private enable_shared_from_this
+ friendshared_ptr
seems 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