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