[cfe-dev] Ideas for member access

Douglas Gregor dgregor at apple.com
Sun Feb 8 12:05:09 PST 2009


On Feb 8, 2009, at 11:18 AM, Sebastian Redl wrote:

> Douglas Gregor wrote:
>>
>> On Feb 8, 2009, at 7:57 AM, Sebastian Redl wrote:
>>> It seems that, after templates, the only big C++ feature that's  
>>> far from
>>> complete is member access checking. So I'd like to know if anyone  
>>> has
>>> already thought about this and has some design ideas.
>>
>>
>> My only thought about member access checking is that we can safely
>> ignore it for a quite a while longer, if we want to, since a
>> well-formed C++03 program can still compile even if we don't do any
>> access checking.
> True, but I need something to do.

Oh, well, in *that* case... :)

I have a mental checklist of easily-separable features and semantics  
that need to be implemented. If it would be helpful, I could augment  
the C++ status page with a "C++ suggested TODO list" of such tasks.

>
>> That said, I think part of the design for access checking is going to
>> need the ability to either store a list of access checks that still
>> need to be performed, or to be able to walk over an AST and perform
>> access checking later. This is required for, e.g., out-of-line member
>> definitions:
>>
>>  class X {
>>    typedef int type;
>>
>>  public:
>>    type f();
>>  };
>>
>>  X::type X::f() {  // delay access checking of X::type until we know
>> that we're defining a member function within 'X'
>>  }
> Good point. This makes the most trivial way of implementing this  
> impossible.
>
> On the other hand, is there any place we need to delay checking other
> than the typename in a declspec and the name of a declarator?

IIRC, we also need to delay access checking within templates, even  
when name lookup finds something within a non-dependent type or non- 
type-dependent expression. So this kind of delayed-checking mechanism  
would have to be somewhat general (or we'd have to ignore all access  
control within templates, which is also possible).

   - Doug



More information about the cfe-dev mailing list