This is the mail archive of the
mailing list for the GCC project.
Re: enable_shared_from_this fails at runtime when inherited privately
- From: Christian Schneider <cschneider at radiodata dot biz>
- To: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- Cc: llvm-dev at lists dot llvm dot org, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, christian at ch-sc dot de, premmers at radiodata dot biz
- Date: Thu, 29 Aug 2019 12:49:29 +0200
- Subject: Re: enable_shared_from_this fails at runtime when inherited privately
- References: <email@example.com> <CAH6eHdRo=FX8DnS8-xpPfgWeCv5H2C42ztxDaSjnQaU_vEH37Q@mail.gmail.com>
Am 29.08.19 um 12:07 schrieb Jonathan Wakely:
On Thu, 29 Aug 2019 at 10:15, Christian Schneider
I just discovered, that, when using enable_shared_from_this and
inheriting it privately, this fails at runtime.
I made a small example:
#define prefix std
auto a = prefix::make_shared<foo>();
auto b = a->get_sptr();
This compiles fine, but throws a weak_ptr exception at runtime.
I'm aware, that the implementation requires, that
enable_shared_from_this needs to be publicly inherited, but as a first
time user, I had to find this out the hard way, as documentations (I
use, ie. cppreference.com) don't mention it, probably because it's not a
requirement of the standard.
It definitely is a requirement of the standard. The new wording we
added via http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0033r1.html#spec
says that the base's weak_ptr is only initialized when the base class
is "unambiguous and accessible". It doesn't say that an ambiguous or
inaccessible base class makes the program ill-formed, so we're not
allowed to reject such a program. >
I see. As far as I understand, this sentence was removed:
Requires: enable_shared_from_this<T> shall be an accessible base class
of T. *this shall be a subobject of an object t of type T. There shall
be at least one shared_ptr instance p that owns &t.
As far as I read it, this required enable_shared_from_this to be public
accessible. Do you know (or someone else), why it was removed?
I find it a little, umm..., inconvenient, that the compiler happily
accepts it when it is clear that it never ever can work...
When Boost wants to follow the standard, then yes. If not i would see it
as a feature, see above :)
On the other hand, if you compile the code with additional
-Dprefix=boost (and needed boost stuff installed, of course), it gives a
compiler error (
gcc: 'boost::enable_shared_from_this<foo>' is an inaccessible base of 'foo';
clang: error: cannot cast 'boost::shared_ptr<foo>::element_type' (aka
'foo') to its private base class 'boost::enable_shared_from_this<foo>')
That seems like a bug in Boost.
I'm think, it would be helpful, if the std implemntions also would fail
at compile time already, and wanted to ask if this would be
No, that would not conform to the standard.