[cfe-dev] Beginnings of C++ access control (and question about standard)

Sebastian Redl sebastian.redl at getdesigned.at
Sun Apr 26 05:00:10 PDT 2009


Sorry for taking so long to respond.

Tim Northover wrote:
> On Monday 20 Apr 2009 18:22:20 Sebastian Redl wrote:
>   
>> Tim Northover wrote:
>>     
>>> Am I wrong in my interpretation of that particular paragraph; or is that
>>> actually forbidden on other grounds (perhaps ambiguity resolution?); or
>>> is gcc wrong?
>>>       
>> Comeau agrees with GCC, so I'd say they're right. This is because the N
>> that is found would be the N within N that Y inherited as private.
>>     
>
> I seem to have found similar in an even simpler example where hiding private 
> bases doesn't come up:
>
> class N {
> protected:
>         int m;
> };
>
> class P : public N {
>   int getX(N n) {
>     return n.m;
>   }
> };
>
> g++ (and comeau) complain that m is protected here, but I just can't see how 
> this can fail the condition:
>
> "— m as a member of N is protected, and R occurs [...] or in a member or 
> friend of a class P derived from N, where m as a member of P is public, 
> private, or protected, or"
>
> I can see why it'd make sense to make some demand that N be a 
> pointer/reference that's actually convertible to a P, but I can't see where 
> the standard actually does so.
>
> Anyone got any thoughts?
>   
Practically speaking, we have every compiler doing it one way, it makes
sense to do it this way, and the standard isn't explicit about it, so
obviously we should do it the same way as everyone else. The example
typically brought up is this:

class N {
protected:
        int m;
};

class O : public N {
};


class P : public N {
  int getX(O o) {
    return o.m; // P has no business messing with O's internals.
  }
};


So, it makes sense. I think the justification from the standard point of
view is in this sentence fragment: "where m as a member of P is public,
private, or protected". n.m (or o.m) here is not a member of P. If n was
a reference to N, then it could perhaps be one, but we can't prove it.
So it makes no sense to speak of m as a member of P, so the condition is
false.

Not a very good justification, I have to admit. You should ask on
comp.std.c++ for clarification.

I'll look at the patch in your later post.

Sebastian



More information about the cfe-dev mailing list