🚀 go-pugleaf

In article <48gmat$i43@engnews1.eng.sun.com>, clamage@Eng.Sun.COM wrote:

> You can allocate raw storage, construct an object in it, destroy the
> object, and construct a new object of different type at the same location.
> The key point is whether you can do that during execution of a member
> function on behalf of the original object.
> 
> I think the answer is no.

I beg to differ.  I believe the issue of destroying an object from within
a member's execution has been resolved, and the answer was that it's OK:

    void A::f() { delete this; }  // OK

The catch is that the member function may not make any use of the object
after it's been destroyed.  Use of the raw memory is OK if it hasn't been
deallocated.

Here's a somewhat more robust version of the example:

  virtual void Derived::f() {
    if (--n == 0) {
      void *mem = dynamic_cast<void*>(this);  // start of complete object
      this->~Derived();
      new (mem) Base;
    }
  }

I agree that this is pretty ugly, but I think the current working paper
makes it well-formed.

Since non-array operator new is passed the *exact* size of the object being
allocated, the address point of the complete object is guaranteed to be the
same value as was returned by operator new when the object was allocated.
So by using dynamic_cast to get the start of the complete object, you also
get the start of the allocated memory, ensuring that the placement new
will be well-formed.

Of course when the object is deleted it will be a base class object, so
if the base and derived classes overrides operator delete, the base class
operator delete will be called.  This may be somewhat surprising, but it
should be well-formed under the (yet to be written, but informally agreed
upon) rules for the interaction of operator new, operator delete,
constructors, destructors, new-expressions and delete-expressions.

-- 
Bill Gibbons
bgibbons@taligent.com

---
[ 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. ]