Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!tut.cis.ohio-state.edu!att!westmark!mole-end!mat
From: mat@mole-end.UUCP (Mark A Terribile)
Newsgroups: comp.lang.c++
Subject: Re: Efficient compilation of virtual functions
Summary: But is unplanned derivation a good thing?
Message-ID: <430@mole-end.UUCP>
Date: 3 Sep 90 03:28:39 GMT
References: <1990Aug22.193347.18486@ux1.cso.uiuc.edu> <6428@wolfen.cc.uow.oz> <417@taumet.com>
Organization: mole-end--private system.  admin: mole-end!newtnews
Lines: 62

> |Paul> The problem then is that the compiler needs to know that subclass has
> |Paul> nothing derived from it. This is not possible with separate compilation.
> 
> |It would be nice to be able to declare a class or even a member
> |function as "leaf". Even if we disregard the possible optimizations,
> |it would add to the programmers ability to document the classes.
> 
> I don't think I agree with this.  If you declared a leaf node, you 
> would be prohibiting further reuse of the class by deriving from it.
> How do you know that another object with slightly more specialized
> behavior will never be needed in the future?

Well, from the point of view of the developer who is trying to build
a planned, engineered, and maintainable product, this inability may
indeed be a good thing.  All that is necessary in your case is to
create an intermediate class from which further derivation is possible,
and a leaf class with no changes from the `derivable' class.

An alternative would be to block the derivation of all classes except
those declared in the `leaf' declaration.

If you DON'T know what does or does not derive from a class, your ability
to alter it once the product is released is very limited, just as you must
be careful not to alter a global variable upon which anything may depend.

In the real world, some degree of special care is needed to design and
create a class with a good protected interface.  Inheritance is an
engineering tool, not a means to avoid engineering.  Dare I say that
there is `no silver bullet'?  This is especially true for a language
that is meant for large projects.  SmallTalk may have been meant for
rapid prototyping or for teaching; C++ seems better as a way to move
some of the mid-level specs and architectural design into the code itself.
 
> Someone needing this capability while also using your code would be
> required to duplicate the existing code with new names, then create
> conversion functions to your old class hierarchy.  This seems like a
> steep price to pay for some special-case micro-optimization.

Why the conversion functions?  Yes, you would have to duplicate code, but
you could still derived the class from the leaf class's ultimate base
class(es).
 
> I believe the original poster wanted to optimize calls to a virtual
> function of the current class.  While this is potentially dangerous,
> the language already provides the mechanism to do this.  Example:
  . . .
> C::bar()
> {
>     ...
>     foo();	// virtual call
>     ...
>     C::foo();	// not a virtual call

Actually, I believe that the point was to allow the compiler to perform
the optimization.  Forcing it on the programmer is unsafe; as much as I
hate duplicated code, I would prefer my efficiencies to be properly
engineered rather than either hacked in as a hard-to-find derivation or
built up like a house of cards in my code.
-- 

 (This man's opinions are his own.)
 From mole-end				Mark Terribile