[cfe-dev] Handling inherited virtuals
Douglas Gregor
dgregor at apple.com
Mon Feb 9 08:53:04 PST 2009
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>
More information about the cfe-dev
mailing list