Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!att!att!westmark!mole-end!mat
From: mat@mole-end.UUCP (Mark A Terribile)
Newsgroups: comp.lang.c++
Subject: Re: Cfront problem with operator delete?
Summary: Well, it's SUPPOSED to work that way ...
Message-ID: <463@mole-end.UUCP>
Date: 2 Jan 91 06:47:54 GMT
References: <1990Dec20.204737.25444@sco.COM>
Organization: mole-end--private system.  admin: mole-end!newtnews
Lines: 39

In article <1990Dec20.204737.25444@sco.COM>, tom@sco.COM (Tom Kelly) writes:

> 		   ...  I derive from that base class, inheriting new
> and delete.  I expect the new and delete operators to be called with
> the appropriate size of the derived objects.

So far, so good.
 
> It works fine for operator new().  However, the second argument to 
> operator delete() is always the same, and reflects the size
> of the base class.

> According to E&S (ARM), p. 283:
 
> 	...  The size passed ...  will be correct either if the
> 	type of the pointer argument to the delete operator is
> 	the exact type of the object (and not, for example, just the
> 	type of base class) or if the type is that of a base class
> 	with a virtual destructor.

> Since all my deletes are using the exact type of the object, I expect
> delete to get the right size.
 
> Am I mis-interpreting the ARM and doing something wrong, or is this
> a bug in cfront?  If the code ifdef'd with FIX is compiled in, then
> the program works and gets the expected answer.

I think you have a bug.  If it is any consolation, you probably should
use the virtual destructor anyway unless you are very badly cramped for
space.  It's just plain safer.

My own view is that C++ ought to disable SOMETHING when inherited destructors
are not virtual.  The derived* => base* conversion might be a candidate; so
might the availability of  operator delete in derived classes.  There is a
serious weakness in C++ in this area, I think.
-- 

 (This man's opinions are his own.)
 From mole-end				Mark Terribile