About FunctionDeclaration and ClassFunctionDeclaration

[Sven Brauch]

I just checked, a dynamic_cast is about as expensive as a virtual
function call. So this does indeed not make any difference
performance-wise. My "PS" can thus be safely dismissed. :)

Am 9. März 2012 12:43 schrieb Andreas Pakulat <apaku at gmx.de>:
> On 09.03.12 12:24:43, Milian Wolff wrote:
>> On Friday 09 March 2012 12:01:23 Andreas Pakulat wrote:
>> > On 09.03.12 10:31:23, Milian Wolff wrote:
>> > > On Friday 09 March 2012 00:42:18 Sven Brauch wrote:
>> > > > [1] PS: While we're at that topic, it would be great to have a few
>> > > > more of those functions anyways, to avoid dynamic_cast type checking.
>> > > > For example, isClassDeclaration() would be useful for me. Is there any
>> > > > general objection in adding such things?
>> > >
>> > > If it's worth it... Personally I rarely have a case where I just need to
>> > > know what kind a declaration is, most often I'll also have to call one of
>> > > the methods of the more concrete type. Hence something like:
>> > >
>> > > if(c = dynamic_cast<...>(dec)) {
>> > >
>> > >  c->foo();
>> > >
>> > > }
>> > >
>> > > Adding an additional virtual function call here just to save one dynamic
>> > > cast in some conditions... I doubt this is much faster. And of course not
>> > > more readable! I'd like to see some benchmark that shows how the dynamic
>> > > cast compares to the virtual function call :)
>> >
>> > Not having much of a clue of how duchain is designed (and probably
>> > unrelated to the problem at hand), I wonder why
>> > AbstractFunctionDeclaration does not inherit from Declaration. The extra
>> > "MergeAbstractFunctionDeclaration" template tripped me over last night
>> > when I looked at the inheritance chain.
>> >
>> > From a design point of view I don't think it makes much sense, but I
>> > guess I'm simply missing something vital to understand the reason.
>>
>> <snip>
>>
>> The reason is that this would make it impossible to have a
>> ClassFunctionDeclaration that is also a ClassMemberDeclaration (to get stuff
>> like StorageSpecifier & AccessPolicy). The latter is a Declaration as well
>> after all.
>
> I see, though its not impossible to work with a diamon-shape inheritance
> in C++ I can understand that one tries to avoid it if possible. In this
> case though I don't think it would've created problems since
> ClassMemberDeclaration does not override any API from Declaration, it
> merely adds in some more stuff. So in fact maybe ClassMemberDeclaration
> should've been the mixin type and AbstractFunctionDeclaration the one
> subclassing Declaration...
>
> Anyway, I was merely interested.
>
> Andreas
>
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel