Topic: Deleting an object pointed by void*...HELP


Author: robina@wv.mentorg.com (Robin Albrecht)
Date: Wed, 08 Dec 1993 22:53:12 GMT
Raw View
In article <CHoxz4.J4v@cbnewse.cb.att.com>, grumpy@cbnewse.cb.att.com (Paul J Lucas) writes:
|> From article <1993Dec7.090121.23926@etrog.se.citri.edu.au>, by glenn@catt.citri.edu.au (Glenn Jayaputera):
|> > I am wondering if there is a possibility of deleting an object that is
|> > pointed by a void pointer.  Is it possible, or it is totally non-sense.
|>
|>  Both.

Any comments on this example from the ARM p. 66:

   void X::my_delete(Arena* a)
   {
      this->X::~X();

      if (a)
         a->free((void*)this);
      else
         delete (void*)this;
   }

Based on this example, I had concluded -- possibly erroneously -- that

   delete (void *) p;

could be counted on to call

   ::operator delete(p);

without attempting to call any destructor, and would therefore be valid
in circumstances in which calling

   delete p;

would be valid.

Followups to comp.std.c++.

|> --
|>  - Paul J. Lucas
|>    AT&T Bell Laboratories
|>    Naperville, IL

--
Robin Albrecht
Mentor Graphics, IC Division
Email: robin_albrecht@mentorg.com




Author: brett@wv.mentorg.com (Brett Stutz @ PCB x5574)
Date: Wed, 08 Dec 1993 23:41:40 GMT
Raw View
In article <1993Dec08.225312.22657@news.mentorg.com>, robina@wv.mentorg.com (Robin Albrecht) writes:
|> In article <CHoxz4.J4v@cbnewse.cb.att.com>, grumpy@cbnewse.cb.att.com (Paul J Lucas) writes:
|> |> From article <1993Dec7.090121.23926@etrog.se.citri.edu.au>, by glenn@catt.citri.edu.au (Glenn Jayaputera):
|> |> > I am wondering if there is a possibility of deleting an object that is
|> |> > pointed by a void pointer.  Is it possible, or it is totally non-sense.
|> |>
|> |>  Both.
|>
|> Any comments on this example from the ARM p. 66:
|>
|>    void X::my_delete(Arena* a)
|>    {
|>       this->X::~X();
|>
|>       if (a)
|>          a->free((void*)this);
|>       else
|>          delete (void*)this;
|>    }
|>
|> Based on this example, I had concluded -- possibly erroneously -- that
|>
|>    delete (void *) p;
Since the argument for the delete operator is a void *, no destructor will
be called.
|>
|> could be counted on to call
|>
|>    ::operator delete(p);
Here, if p is an X*, this line of code will result in a call to X::~X()
|>
|> without attempting to call any destructor, and would therefore be valid
|> in circumstances in which calling
|>
|>    delete p;
|>
|> would be valid.
|>
|> Followups to comp.std.c++.
|>
|> |> --
|> |>  - Paul J. Lucas
|> |>    AT&T Bell Laboratories
|> |>    Naperville, IL
|>
|> --
|> Robin Albrecht
|> Mentor Graphics, IC Division
|> Email: robin_albrecht@mentorg.com




Author: grumpy@cbnewse.cb.att.com (Paul J Lucas)
Date: Thu, 9 Dec 1993 05:17:44 GMT
Raw View


Author: kanze@us-es.sel.de (James Kanze)
Date: 09 Dec 1993 13:52:33 GMT
Raw View
In article <CHr5Dn.LIH@cbnewse.cb.att.com> grumpy@cbnewse.cb.att.com
(Paul J Lucas) writes:

|> From article <1993Dec08.225312.22657@news.mentorg.com>, by robina@wv.mentorg.com (Robin Albrecht):
|> > In article <CHoxz4.J4v@cbnewse.cb.att.com>, grumpy@cbnewse.cb.att.com (Paul J Lucas) writes:
|> > |> From article <1993Dec7.090121.23926@etrog.se.citri.edu.au>, by glenn@catt.citri.edu.au (Glenn Jayaputera):
|> > |> > I am wondering if there is a possibility of deleting an object that is
|> > |> > pointed by a void pointer.  Is it possible, or it is totally non-sense.
|> > |>
|> > |>  Both.

|> > Any comments on this example from the ARM p. 66:

|>  [ example elided ]

|> > Based on this example, I had concluded -- possibly erroneously -- that

|> >    delete (void *) p;

|> > could be counted on to call

|> >    ::operator delete(p);

|> > without attempting to call any destructor, and would therefore be valid
|> > in circumstances in which calling

|> >    delete p;

|> > would be valid.

|>  You might think that, and so might I.  The catch is that this
|>  example is in the commentary.  Obviously, you can't "new void"
|>  (objects of type void can not be created); if you can't create
|>  them, how can you destroy them?

The real catch lies elsewhere.

|>  This, IMHO, if intended to be legal, must be mentioned
|>  explicitly because, by my above statements, it is a special
|>  case and its semantics must be defined precisely--not left for
|>  the reader to infer.

Having followed some recent discussions in the standarads committee, I
don't think that this was intended to be legal, but for an entirely
different reason (which also breaks my favorite idiom of using an
explicite call to the destructor, followed by placement new, for
assignment).

Basically, there is no guarantee that the physical address pointed to
by the pointer to the object is actually the first byte of the object.
But this is what the cast to void returns.  Suppose, for example, that
the function 'operator new' actually allocates memory at the address
0x10000.  It is quite possible that the operator new (not the
function) returns a different address (to somewhere within the
allocated memory).  Since the implementation "knows" the change it has
made to the return value of 'operator new' (the function), it can make
the corresponding correction when calling 'operator delete' (the
function).  This change may depend on the type of the pointer.

In fact, I suspect that this actually happens in a lot of
implementations in the case of arrays.  If the type of the 'new' is a
pointer to a class, the implementation allocates an extra word in
front of the pointer.  When returning memory to the free space arena
(with operator []delete), the system will decrement the pointer
correspondingly if and only if it is a pointer to class type.

Although I know of no implementations where this is a problem for
non-arrays, I also know of no words in the ARM or the working papers
which would render such an implementation illegal.  The question is
still under discussion in the standardization committee.
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung