🚀 go-pugleaf

In article <4e1jfb$1ea@fsgm01.fnal.gov> b91926@fsgm01.fnal.gov (David
Sachs) writes:

|> clamage@Eng.Sun.COM (Steve Clamage) writes:

|> >In article 460@news.bridge.net, David Byrden <100101.2547@compuserve.com>
|> >writes:

    [...]
|> >>but there is no matching version of 'delete'? Are we supposed to use both
|> >>destroy() and deallocate() to get rid of that object?

|> >Yes. In the above example:
|> >	p->~T();
|> >	operator delete(p, x);

|> How can you guarantee that the first argument to operator delete
|> will be correct? It might be slightly safer to write:

|> 	void* q = p;  // evaluate before destruction

Must be ``void* q = dynamic_cast< void* >( p )''.  Also, of course, T
must have at least one virtual function.  (Not really an additional
constraint; if it didn't have a virtual destructor, the normal case
with non-placement new and delete is undefined.)

|> 	p->~T();
|> 	operator delete(q,x);

|> and I am not sure if this is guaranteed to be safe.

If T is a class type with a virtual destructor, yes.

If T is the actual type of the complete object, and the object is not
an array, yes.

If T is an array type, the problem becomes more interesting.  The
correct solution is to not use the built-in array types, and thus
avoid the problem entirely.  (The problem only occurs when memory is
allocated by means of placement new, but freed with a direct call to
operator delete.  In all of the implementations of vector classes I've
seen, the memory is allocated with a direct call to operator new, so
the problem doesn't occur.)

--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
                -- A la recherche d'une activiti dans une region francophone
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]