About FunctionDeclaration and ClassFunctionDeclaration

[Andreas Pakulat]

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