[cfe-dev] Handling inherited virtuals

[Douglas Gregor]

On Feb 8, 2009, at 10:42 AM, Piotr Rak wrote:

> Hi Sebastian,
>
> 2009/2/8 Sebastian Redl <sebastian.redl at getdesigned.at>:
>> Naive searching is pretty much a no-starter. We have to make a
>> depth-first search through the entire inheritance hierarchy,  
>> collecting
>> pure functions, and then check every class on the path back to see  
>> if it
>> overrides these functions, so we can kick them out again, which  
>> means a
>> lot of work checking if a function overrides another, which we  
>> already
>> did above.
>> Therefore we should probably keep a list of abstract functions for  
>> each
>> class. Whether this should be part of another lookup structure is a
>> different question.
>>
>> Comments? Ideas?
>
> Yes, I think we need such structure, member lookup would be quite
> expensive with out it.
> It will more or less correspond v-table of class, if we will try to
> avoid it here and do tricks with lookup (which would be slow), we will
> need build it in Codegen, right?

CodeGen will do something like this, yes, but it's likely that it will  
need to walk the list of non-static member functions linearly anyway  
to perform vtable layout. Besides, from a performance perspective, we  
have to do vtable layout far fewer times than we need to check "does  
this override a virtual?".

> This list could hold also members from base class by introduced
> using-declarations, but I am not quite sure (they can also appear at
> any DeclScope with slightly different semantic).
>
> We we also have to keep track of C++0x deleted/(defaulted?) members  
> someday...


Deleted functions are very, very easy; it's just a bit that we check  
before actually using a function name (after overload resolution).

Defaulted members will take a little more work, but right now that  
work mostly involves actually synthesizing the implicitly-defined  
members when we need them. Currently, we just pretend that they exist :)

	- Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20090209/b862632d/attachment.html>