From -526286214730111193 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,db4807a3f0a1e742 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1994-08-05 03:27:33 PST Newsgroups: comp.std.c++ Path: bga.com!news.sprintlink.net!hookup!yeshua.marcam.com!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!EU.net!sun4nl!cwi.nl!olaf From: olaf@cwi.nl (Olaf Weber) Subject: Re: Multiple inheritance and delete In-Reply-To: jason@cygnus.com's message of Thu, 4 Aug 1994 01:05:34 GMT Message-ID: Lines: 43 Sender: news@cwi.nl (The Daily Dross) Nntp-Posting-Host: havik.cwi.nl Organization: CWI, Amsterdam References: <1994Aug02.045000.2253@corona.com> Date: Fri, 5 Aug 1994 08:00:50 GMT In article , jason@cygnus.com (Jason Merrill) writes: >>>>>> Olaf Weber writes: >> There are two issues here: (1) should all classes be polymorphic with >> respect to RTTI and destructor calls, and (2) should all member >> functions of a class be virtual. >> With repect to (1): there are ways of implementing this with little >> run-time costs for people who don't use it. > But would doing so be useful? If people want their classes to be > polymorphic with respect to destructor calls, they should make their > destructors virtual. That's what virtual is for. I certainly agree with this sentiment when applied to normal member functions. Steve Clamage pointed out some good reasons why you might want member functions to be non-virtual in a class that is ostensible meant to be derived from (it has a virtual destructor). [comp.lang.c++ article <31p84a$k27@engnews2.Eng.Sun.COM>, "Re: virtual iostream methods? why not?"] Destructors are special however, and a guarantee that the correct destructor will be called for an object is worth something, but it has to be balanced against the costs. One way of accomplishing safe destruction would be a requirement that a class can only be derived from if it has a virtual destructor. However, the code excerpt from the Standard Template Library shows some very reasonable use of derivation from classes without virtual destructors. There would be a space overhead for all objects, even if they live on the stack only, which is not acceptable. A problem with more clever methods is that rolling you own memory management for a class would become more complex, as users of the class will assume that deletion through a pointer to it will work, even if the object is of a derived class. In all, I don't think it is worth the extra hassle. Of course, with garbage collection most of the infrastructure required will be there in any case, and I'd like to see it offered (as an extension) in that case. -- Olaf Weber