[cfe-dev] [PATCH] Friend class cannot access protected field of parent

Olivier Goffart ogoffart at kde.org
Tue Jun 8 01:56:50 PDT 2010


Le Tuesday 08 June 2010, John McCall a écrit :
> On Jun 8, 2010, at 12:23 AM, Olivier Goffart wrote:
> > So you think it is better not to try to make it work, even for the non-
> > template case?
> 
> Yes.  Like I said, I don't think this is an intended feature;  I think it's
> a drafting error.  [class.access.base] contains many repetitions of the
> phrase "member or friend";  I think someone just wrote "member or friend"
> here without really thinking.  I think when they were drafting the example
> in [class.protected] they were only thinking about the effect of the
> protected access restriction, not whether the member itself was accessible
> from the naming class.  I'm willing to consider evidence in the form of a
> DR that I'm wrong, but I don't really want to implement the rule, and I'm
> not going to implement it as long as it's undecidable.

Alright.
Still, according to the examples in [class.protected], it does not seem to be 
a simple mistake.

Especially the
p2->B::i = 4; // OK (access through a D2, even though naming class is B)
B::j = 5; //OK (because refers to static member)
in the fr function.

Those examples do not compile with pristine clang, but does compile with the 
patch.


> Since I think this only affects people trying to compile Qt itself (rather
> than people relying on Qt headers), I don't think it qualifies for a
> workaround. It should be really easy to fix in the source, though.

Not trivial, but not that difficult, true.

 
> Also, thank you for reminding me to add "introduces crazy dependencies on
> instantiation order" to the list of reasons why this is a terrible mistake.
> :)

Thanks for your comments.

-- 
Olivier




More information about the cfe-dev mailing list