Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!sbi!pivot-sts!swampthing!wfl
From: wfl@swampthing.sbi.com (W. Linke CPE)
Newsgroups: comp.lang.c++
Subject: Re: Pure virtual destructors are illegal?
Summary: legalistic fine points...
Keywords: virtual destructor
Message-ID: <191@swampthing.sbi.com>
Date: 6 Jun 91 20:32:23 GMT
References: <1991Jun1.192610.18321@borland.com> <1991Jun5.145047.8499@world.std.com>
Organization: Salomon Brothers - NJ
Lines: 35

In article <1991Jun5.145047.8499@world.std.com>, wmm@world.std.com (William M Miller) writes:
> wfl@swampthing.sbi.com (W. Linke CPE) writes:
> > Pure virtual functions work the same way, subject to derivation to a
> > non-abstract class.  Note that section 10.3 of the ARM, which talks about
> > [...] It doesn't say the function needn't be defined.
> 
> Yes, it does!  The second paragraph of 10.3, page 214, says, "A pure virtual
> function need be defined only if explicitly called with the qualified-name
> syntax (section 5.1)."

I think we agree; when I said "subject to derivation to a non-abstract class",
I meant to refer only to derived classes which no longer contain any pure
virtual functions; i.e., all the virtual member functions have been declared 
at some point in the derivation chain without the "= 0" pure-specifier.
Then the quoted sentence doesn't apply, because there aren't any pure
virtual functions in the class, and we're back to trying to figure out
whether ordinary virtual functions need to be defined.

As to that question, I'll state an opinion, just to see what else I can
learn: the standard should state that all non-pure virtual member functions
must be defined, even if they are not explicitly called.  My reasoning is that
this should be the simplest to implement, and causes no real pain since a
developer can provide dummy inline definitions for unused functions.  The
only argument against it that I can think of is that the compiler would be
requiring the developer to provide routines which aren't needed by the
application.  But my counterargument is that the language already does
something similar, so a little more wouldn't hurt!  I'm referring to the
origin of this thread, where I declared a pure virtual destructor and was
forced to define the destructor function because the compiler generated
a qualified-name reference to it from the derived class destructor.
I don't need or call the base destructor, but must supply it because the
compiler creates code which calls it.

Bill Linke
uunet!sbi!gort!wfl