Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!rutgers!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ames!amdahl!nsc!voder!decvax!roger
From: roger@decvax.UUCP (Roger H. Scott)
Newsgroups: comp.lang.c++
Subject: Re: True Virtual
Message-ID: <80@pascal.decvax.UUCP>
Date: 6 Feb 90 08:34:34 GMT
References: <4800082@m.cs.uiuc.edu> <4924@drutx.ATT.COM> <10382@alice.UUCP> <4982@drutx.ATT.COM> <10424@alice.UUCP>
Reply-To: roger@procase.UUCP (Roger H. Scott)
Organization: proCASE Corporation, Santa Clara, CA
Lines: 23

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.