🚀 go-pugleaf

In article <DHzpGF.DCt@shlnews.shl.com>, wmooney@shl.com (William Mooney) writes:
|> 
|> John Max Skaller <maxtal@suphys.physics.su.oz.au> says:
|> >Since on many systems virtual destructors
|> >greatly increase the costs associated
|> >with an object (size, dispatch efficiency, etc),
|> >there's a performance reason (as well as the
|> >obvious layout control reason) for not
|> >coding a virtual destructor in a class.
|> 
|> Hmmm, this really sounds like a case of "do I plan for reuse now, or
|> wait until I need to reuse and then double check all of my parent
|> classes" -- both approaches have their merits.

I would say it is "plan for reuse where it makes sense".

Some classes simply do not make sense in polymorphic usage.  In these
cases the class should be designed NOT to be derived from. Also, virtual
destructors are only needed if you are going to be deleting an object of
the class using a base class pointer - so add-on deriviation is still OK
as long as one never assigns the derived class to a base class pointer.

There are fundamentally three or four types of classes, each with different
requirements:

1. Stand-alone classes: these are classes that are complete in themselves,
			and for which deriviation is of doubtful significance.

2. Abstract classes:    these are classes that define an interface and a baseline
			implementation, but do not make sense as the type of
			an object.

3. Leaf classes:	these are classes that implement a concrete type based on
			an abstract interface.

and maybe
4. Mix-in classes:	these are classes that add features or capabilities to
			objects of other types.

Type 1 classes should have *no* virtual functions, and should never be
used as a public base class. Type 2 classes need at least one pure virtual
function, a virtual destructor, and maybe a set of basic algorithms. They
*must* be used as base classes.  Type 3 classes implement the virtual
functions defined in their base classes.

|> 
|> What you can do if the cost of virtual destructors on standalone
|> classes concerns you, yet you or someone else *may* derive from them
|> at some point in time, is to wrap the virtual keyword like so:

It is time to define classes as either usable as base classes or not.
And put this information in the *documentation*.  Then, since it is documented,
if somebody later derives from it, any problems are their fault.


Keep base classes distinct from stand-alone classes from the very beginning
of the design process.

-- 
swf@elsegundoca.attgis.com		sarima@netcom.com

The peace of God be with you.


[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]