wfl@swampthing.sbi.com (W. Linke CPE) (06/01/91)
It seems that you can't have a pure virtual destructor, but the compiler
(Sun SPARCstation cfront 2.00.02) doesn't object. Consider the following:
class Base {
public:
Base() { }
virtual ~Base() = 0; // bad!
};
class Derived : public Base {
public:
Derived() { }
~Derived() { }
};
main()
{
Derived instance;
}
This compiles successfully, but when you try to link a load module
from it the linker fails, saying it can't find " ___dt__4BaseFva ".
This actually makes sense, because a virtual destructor is different
from other virtual functions. When the Derived 'instance' is destroyed,
both ~Derived() and ~Base() will be called, just as with a non-virtual
destructor. What 'virtual' gives you is correct destruction even when
the object is accesed via a base class pointer, such as:
Base *bp = new Derived;
delete bp; // both ~Derived() and ~Base() called
whereas if the destructor weren't virtual, only ~Base() would be called.
But by declaring ~Base() to be pure virtual, there actually is no ~Base()
routine, so the linker reports it as an undefined symbol. It seems to
me that the compiler should either flag pure virtual destructors
as syntax errors, or generate an internal "null" ~Base() destructor
for classes derived from Base which provide their own destructor.
Do other compilers/versions catch this problem?
Bill Linke
uunet!sbi!gort!wflpete@borland.com (Pete Becker) (06/02/91)
In article <183@swampthing.sbi.com> wfl@swampthing.sbi.com (W. Linke CPE) writes: > >It seems that you can't have a pure virtual destructor, but the compiler >(Sun SPARCstation cfront 2.00.02) doesn't object. Consider the following: > > class Base { > public: > Base() { } > virtual ~Base() = 0; // bad! > }; "Pure virtual" does not mean "no implementation"! It only means that a derived class must override the pure virtual function. In the case of a pure virtual destructor, since it will be called by the destructor for the derived class, you must provide an implementation. -- Pete
masa@hpsciz.sc.hp.com (Masayoshi Habu) (06/04/91)
In comp.lang.c++, pete@borland.com (Pete Becker) writes:
"Pure virtual" does not mean "no implementation"! It only means that
a derived class must override the pure virtual function. In the case of a
pure virtual destructor, since it will be called by the destructor for the
derived class, you must provide an implementation.
-- Pete
Please correct me if I am wrong. A pure virtual function usually has no
implementation because the intention is to catch a run-time error if this
function is never overridden and called somehow. However, in this case it
does not make sense to have a pure virtual destructor because even though
it is virtual, this destructor is called eventually anyway. So my opinion
is that the compiler should reject a pure virtual destrcutor.
What does ARM say about this ?
Masawfl@swampthing.sbi.com (W. Linke CPE) (06/04/91)
In article <1991Jun1.192610.18321@borland.com>, pete@borland.com (Pete Becker) writes: > "Pure virtual" does not mean "no implementation"! It only means that > a derived class must override the pure virtual function. In the case of a > pure virtual destructor, since it will be called by the destructor for the > derived class, you must provide an implementation. Thanks for the correction. After reading this, I studied the ARM some more. and I think I understand. It's not a bug, but there is something a little ungainly about pure virtual destructors, because their nature differs from ordinary pure virtual member functions, as follows: A pure virtual member function *MAY* be defined for the abstract class in which it is declared, but it *MUST* be overridden in some class derived from the abstract class in order to create class objects, but a pure virtual destructor *MUST* be defined for the abstract class in which it is declared, while it *MAY* be "overridden" in classes derived from the abstract class. It's not inconsistent; just not as generalized as it seemed. "Pure virtual" in the above really means two different (overlapping) things. (The overlap is that they both cause their declaration class to be abstract.) Bill Linke uunet!sbi!gort!wfl
wmm@world.std.com (William M Miller) (06/04/91)
wfl@swampthing.sbi.com (W. Linke CPE) writes: > A pure virtual member function *MAY* be defined for the abstract class in which > it is declared, but it *MUST* be overridden in some class derived from the > abstract class in order to create class objects, > > but a pure virtual destructor *MUST* be defined for the abstract class in which > it is declared, while it *MAY* be "overridden" in classes derived from the > abstract class. > > "Pure virtual" in the above really means two different (overlapping) things. Actually, that's not quite correct. "Pure virtual" means the same in both cases; it's just that the special characteristics of destructors cause the compiler to do certain things for you that have to be done manually for ordinary member functions. Specifically, a pure virtual member function "*MUST* be defined" if it is ever invoked; constructors are guaranteed to be invoked. Similarly, a derived class whose base has a destructor is provided a destructor by the compiler if none is explicitly coded, thus implicitly overriding a virtual destructor in the base class. Pure virtual works exactly the same in both cases; there are no special rules for pure virtual destructors, just interactions between rules. -- William M.
wmm@world.std.com (William M Miller) (06/04/91)
masa@hpsciz.sc.hp.com (Masayoshi Habu) writes: > Please correct me if I am wrong. A pure virtual function usually has no > implementation because the intention is to catch a run-time error if this > function is never overridden and called somehow. No, that's not quite right. The basic idea of a pure virtual function is to prevent its class from being instantiated, i.e., to make it abstract. Since derived classes that do not override a pure virtual function inherit the base class's pure virtual, it is impossible to create an object for which a pure virtual function is not overridden. The compiler guarantees that at compile time, not at runtime. A pure virtual function may indeed be defined, if it is to be called (as a destructor will be). Also, an implementation is not required to generate a runtime error if an undefined pure virtual function is invoked; E&S says only that such an occurrence results in undefined behavior (although an implementation that did not produce an error message would be less useful than one that did). > So my opinion > is that the compiler should reject a pure virtual destrcutor. Although I've never needed one, the rationale I've heard for pure virtual destructors was that someone wanted to make a class abstract but that all the ordinary member functions needed to be defined, i.e., not pure. Making the destructor pure virtual is a better choice than defining a dummy pure virtual that is unneeded except for making the class abstract. In any case, I see no need to make destructors a special case, and the core language working group of X3J16, the ANSI C++ Standard Committee, has explicitly affirmed that pure virtual destructors are intended to be included in the language. -- William M. Miller, Glockenspiel, Ltd. wmm@world.std.com
pete@borland.com (Pete Becker) (06/05/91)
In article <185@swampthing.sbi.com> wfl@swampthing.sbi.com (W. Linke CPE) writes: >> "Pure virtual" does not mean "no implementation"! It only means that >> a derived class must override the pure virtual function. In the case of a >> pure virtual destructor, since it will be called by the destructor for the >> derived class, you must provide an implementation. > >A pure virtual member function *MAY* be defined for the abstract class in which >it is declared, but it *MUST* be overridden in some class derived from the >abstract class in order to create class objects, > >but a pure virtual destructor *MUST* be defined for the abstract class in which >it is declared, while it *MAY* be "overridden" in classes derived from the >abstract class. Well, there really is an underlying consistency. Every pure virtual function must be overridden in a derived class, whether it's a destructor or not. The reason you also have to define a pure virtual destructor is that the pure virtual declaration IS a declaration, and tells the compiler not to provide one for you. I agree that this is somewhat less than obvious.
wfl@swampthing.sbi.com (W. Linke CPE) (06/05/91)
In article <1991Jun4.134034.21404@world.std.com>, wmm@world.std.com (William M Miller) writes: > ordinary member functions. Specifically, a pure virtual member function > "*MUST* be defined" if it is ever invoked; constructors are guaranteed to be Actually a virtual member function must be defined if an object of its class is created; the function doesn't need to be invoked. (If pointers to member functions are used, it may not be possible for the compiler to know whether a particular function will be invoked.) The following program fails to link, because there's no function f defined for the vtbl to point to: class A { public: virtual void f(); }; main() { A a; } 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 undefined results from calling a pure virtual function, does so only in reference to calling the function from within a *constructor*, because (I presume) the vtbl might not be initiallized with derived class data yet. It doesn't say the function needn't be defined. > invoked. Similarly, a derived class whose base has a destructor is provided > a destructor by the compiler if none is explicitly coded, thus implicitly > overriding a virtual destructor in the base class. > > Pure virtual works exactly the same in both cases; there are no special > rules for pure virtual destructors, just interactions between rules. Well, I agree there's no inconsistency, but destructors are a special case of member function in that the compiler itself generates direct calls to base class destructors, and that specialness shows through the rules to such an extent that (for instance) C++ textbooks would be better advised to break up the topic into "PV Destructors" and "PV Non-destructors" instead of lumping them together, because the implications of all the rules aren't obvious. (V Destructors and V Non-destructors are different enough to merit this, also.) Then I wouldn't have to waste bandwidth to get educated! :-) Bill Linke uunet!sbi!gort!wfl
wmm@world.std.com (William M Miller) (06/05/91)
wfl@swampthing.sbi.com (W. Linke CPE) writes: > Actually a virtual member function must be defined if an object of its class > is created; the function doesn't need to be invoked. The circumstances under which a virtual function must be defined are under discussion by X3J16. E&S is not much help, as it doesn't address virtual functions specifically at all (see p. 14, "If a function is never called and its address is never taken, it need not be defined"). Existing practice differs, too, not necessarily reflecting your dictum. For example, class X { virtual void f(); virtual void g(); }; void X::f() {} int main() { return 0; } This program links just fine under Zortech 2.12 and Borland Turbo C++ 1.0, but it does not link under cfront 2.0 (Glockenspiel 2.0c), even though no object of class X is created. However, even if things did work the way you said, it would still mean that pure virtual functions need not be defined, since it is by definition impossible to create an object of an abstract class, i.e., one that contains a pure virtual function. > 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 > undefined results from calling a pure virtual function, does so only in > reference to calling the function from within a *constructor*, because > (I presume) the vtbl might not be initiallized with derived class data yet. That's correct. > 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)." -- William M. Miller, Glockenspiel, Ltd. wmm@world.std.com
wfl@swampthing.sbi.com (W. Linke CPE) (06/07/91)
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