ark@alice.UUCP (Andrew Koenig) (02/01/90)
In article <4982@drutx.ATT.COM>, kvt@drutx.ATT.COM (TranKV) writes: > What I meant to ask was if the following works: > > class Foo { > public: > Foo () {} > virtual ~Foo () = 0; > ^^^^^^^^^^^^^^^^^^^^ > // ... > }; Remember that when you destroy an object of a derived class, that involves executing the base class destructor too! Therefore, it doesn't make sense to have a pure virtual destructor, as it would preclude destroying objects not only of that class but of any class derived from it. -- --Andrew Koenig ark@europa.att.com
shopiro@alice.UUCP (Jonathan Shopiro) (02/02/90)
Kim Tran wants to know why he can't have a pure virtual destructor,
that is
class Foo {
virtual ~Foo() = 0; // error
};
The reason is that whenever an object is destroyed, the destructors
for all its base classes are executed. The pure virtual syntax says
that the function will never be called, but its name is a legitimate
function name so the compiler tries to call it in the destructor of
the derived class.
Instead just write an empty destructor, e.g.,
class Foo {
virtual ~Foo() {}; // okay
};
--
Jonathan Shopiro
AT&T Bell Laboratories, Warren, NJ 07060-0908
research!shopiro (201) 580-4229roger@decvax.UUCP (Roger H. Scott) (02/06/90)
In article <10424@alice.UUCP> shopiro@alice.UUCP (Jonathan Shopiro) writes: > > >Kim Tran wants to know why he can't have a pure virtual destructor, >... >Instead just write an empty destructor, e.g., > > class Foo { > virtual ~Foo() {}; // okay > }; > Not such a great idea, unless you like the idea of having a static version of Foo::~Foo() and a vtbl for class Foo in every single module that includes this class declaration. Be *very* careful with inline virtual functions unless you've got space to burn. On a related topic - 2.0 cfront does you the "favor" of deciding that some functions are just "too complicated" to inline and generating "outlined" static versions of the functions IN EVERY SINGLE FILE. Using the +w switch will warn you about some, but I believe not all, of these "favors". I can see giving an optional warning about "too big" inlines, but barging ahead and outlining them is inexcusable. The bloating this caused in our program was so severe that I had to go into our precious $10k cfront source and disable this "feature" - I feel sorry for those who don't have the pleasure of cfront source code.
kvt@drutx.ATT.COM (TranKV) (02/07/90)
In article <10424@alice.UUCP> shopiro@alice.UUCP (Jonathan Shopiro) writes: >Kim Tran wants to know why he can't have a pure virtual destructor, >that is > > class Foo { > virtual ~Foo() = 0; // error > }; > >The reason is that whenever an object is destroyed, the destructors >for all its base classes are executed. The pure virtual syntax says ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >that the function will never be called, but its name is a legitimate ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >function name so the compiler tries to call it in the destructor of ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >the derived class. ^^^^^^^^^^^^^^^^^^ Do we have a case of "double dealings" here? |-) or a symptom of wanting to do a lot behind the scene for the users but ending up lying to them? Well, for one thing, it reminds me of the Iran/Contra trials that are making headlines here. |-) (I just cannot help making the comparision. Just for fun. No offense intended.) Kim Tran Bell Labs kvt@drutx.att.com