https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17314
Anthony Sharp <anthonysharp15 at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |anthonysharp15 at gmail dot com
--- Comment #22 from Anthony Sharp <anthonysharp15 at gmail dot com> ---
I am currently working on a fix for this.
There seems to be three issues here.
1. The primary issue is that in cases of private inheritance, GCC incorrectly
reports that the member is inaccessible because it is protected, when the (more
correct) reason is because it is private. This has required some re-working of
the diagnostics code.
2. The second issue (more of a discussion topic) seems to revolve around
whether virtual inheritance is private by default. A few people here have said
that it is. They might be right, but I am not sure.
3. The third issue seems to be an academic debate on the proper effect of a
virtual private inheritance. Currently, it is possible to inherit from a
private virtual base, e.g. the following code compiles:
class Foo { public: Foo(){} ~Foo(){} };
class A:virtual private Foo { public: A(){} ~A(){} };
class Bar:public A { public: Bar(){} ~Bar(){} };
As Jason Merrill points out, this wasn't intended
(http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#7). Also see
https://stackoverflow.com/questions/3900192/msvc9-0-bug-or-misunderstanding-of-virtual-inheritance-and-friends/3917482.
Apparently MSVC9 has the same quirk.
I'm not sure why the C++ standards committee would say it was intended for the
above code to be ill-formed (or that's what they seem to say). There seems to
me to be no access violation in the above code, technically speaking. Jason
Merrill says '~Bar() calls ~Foo(), which is ill-formed due to access violation,
right? (Bar's constructor has the same problem since it needs to call Foo's
constructor.)', but as far as I'm aware, constructors and destructors aren't
affected by access protection levels. It is possible for a class to derive from
a private class (e.g. see
https://stackoverflow.com/questions/30572835/c-private-class-inheritance).
Jason Merrill points out that there might be some under-the-hood issues with
the above code, and he might be right, but that's beyond my current level of
understanding.
Even if such code is ill-formed, it doesn't really bother me (and nor has it
bothered anyone else, considering this bug report was issued 16 years ago).
Virtual private inheritance is a feature that virtually (haha, get it?) no one
uses, and I think it'd be a waste of time to patch a dead feature. So, I intend
to only fix issue 1. After that, I might create a new bug report to do with 3.,
just so the issue is not buried.
Any thoughts are welcome.
