About FunctionDeclaration and ClassFunctionDeclaration

Milian Wolff mail at milianw.de
Fri Mar 9 11:24:43 UTC 2012


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.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120309/66023dda/attachment.sig>


More information about the KDevelop-devel mailing list