From -6283923343775402780 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,db4807a3f0a1e742 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1994-07-19 08:30:16 PST Newsgroups: comp.std.c++ Path: nntp.gmd.de!Germany.EU.net!EU.net!howland.reston.ans.net!news.cac.psu.edu!news.pop.psu.edu!psuvax1!news.ecn.bgu.edu!mp.cs.niu.edu!fnnews.fnal.gov!gw1!nntpa!not-for-mail From: scalio@hogpf.ho.att.com (-J.SCALIO) Subject: Re: Multiple inheritance and delete Message-ID: Sender: news@nntpa.cb.att.com (Netnews Administration) Nntp-Posting-Host: hogpf.ho.att.com Organization: AT&T References: <306h9v$7f1@fsgi01.fnal.gov> Date: Tue, 19 Jul 1994 14:56:06 GMT Lines: 43 In article <306h9v$7f1@fsgi01.fnal.gov>, David Sachs wrote: >immel@chord.centerline.com (Mark Immel) writes: ... >> >> Suppose I have the following (which breaks with every compiler I try) : >> >> struct A {}; >> struct B {}; >> struct C: A, B {}; >> >> void foo() >> { >> B* b = new C; >> delete b; >> } >> >> It breaks in the sense that delete calls free with a bad address. This >> is a silent failure that can be detected only with a debugging version >> of malloc/free or the like. But much later, you might find out your >> heap is corrupted... >> This code *SHOULD* be legal according to WP 5.3.5 p 2: >> [clipped...] > >The code would work properly if struct B is declared to have >a virtual destructor. e.g. struct B { virtual ~B(){}}; > >I would really like the C++ standard to REQIRE this, but even >with such a requirement, the error would probably be undetectable. This requirement will require every library designer to explicitly declare the destructors of their classes as virtual. It also forces the library designers to explicitly declare *ALL* destructors, since the compiler generated destructor will most certainly *NOT* add the virtual keyword. The requirement and necessary action will increase the size of many classes that otherwise would not declare anything virutal. The standard needs to address the concerns of library designers and users regarding this issue. Library designers should not be responsible in advance for deciding whether anyone should/will derive from their classes.