delete, polymorphism, and multiple inheritence

[Ian McBride]

(was: delete() confusion)

I have a class with multiple base classes. One of these base classes
(base1) has its own new/delete operators and nothing else. Another base
class (base 2) has a virtual destructor. The class with the virtual
destructor has AddRef() and Release() methods, and Release() ultimately does
a "delete this". Can that "delete this" statement somehow find the right
delete method? If it does, it involves a downcast and an upcast to get to
the right place.

Beyond this, I am having a fit trying to figure out, I guess, "delete
visibility" for polymorphic objects. Delete is always static, so it seems
that the class actually being "deleted" needs to have the class with the
correct delete method as a base class. But what if you wind up with
multiple base classes with their own delete operators?

[I have inherited code with a BUNCH of rocket science assembler level memory
management put together by a system architect who got his PhD in memory
strategies. He's gone, and now the new builds are not stable. My first
choice was to comment out ALL new/delete operators and just use the heap,
but the system won't stay in real time under load. I think the memory
management stuff works, but the C++ interface to it -- new and delete -- is
not safe. He was a memory and architect guru but maybe not a C++ guru. I
am no kind of guru, but I'm here on a saturday 2 weeks behind a release
schedule sweating bullets. HELP!!]

[Buster Copley]

Ian McBride wrote:

(was: delete() confusion)

I have a class with multiple base classes. One of these base classes
(base1) has its own new/delete operators and nothing else. Another base
class (base 2) has a virtual destructor. The class with the virtual
destructor has AddRef() and Release() methods, and Release() ultimately does
a "delete this". Can that "delete this" statement somehow find the right
delete method? If it does, it involves a downcast and an upcast to get to
the right place.
I don't know. It worked ten minutes ago... What does VC++ have to say
about the listing I posted?
Beyond this, I am having a fit trying to figure out, I guess, "delete
visibility" for polymorphic objects. Delete is always static, so it seems
that the class actually being "deleted" needs to have the class with the
correct delete method as a base class. But what if you wind up with
multiple base classes with their own delete operators?
Then you should put a using directive in the derived class for the base
class operator delete you want to use, or else provide a new operator
delete in the derived class that does the right thing.
[I have inherited code with a BUNCH of rocket science assembler level memory
management put together by a system architect who got his PhD in memory
strategies. He's gone, and now the new builds are not stable. My first
choice was to comment out ALL new/delete operators and just use the heap,
but the system won't stay in real time under load. I think the memory
management stuff works, but the C++ interface to it -- new and delete -- is
not safe. He was a memory and architect guru but maybe not a C++ guru. I
am no kind of guru, but I'm here on a saturday 2 weeks behind a release
schedule sweating bullets. HELP!!]

Good luck.
Buster.

[Alf P. Steinbach]

On Sat, 19 Jul 2003 13:14:03 -0400, "Ian McBride" <ia************ @yahoo.com> wrote:

(was: delete() confusion)

I have a class with multiple base classes. One of these base classes
(base1) has its own new/delete operators and nothing else. Another base
class (base 2) has a virtual destructor. The class with the virtual
destructor has AddRef() and Release() methods, and Release() ultimately does
a "delete this". Can that "delete this" statement somehow find the right
delete method?
Yes. In the statement "delete p;", if p is of static type T*, and if T
has a virtual destructor, and if the object pointed to is of type D derived
from T, then the D destructor must be invoked first of all, which implies a
dynamic downcast. From there the destructor action moves up the class
hierarchy, until finally (all destructors executed) the memory is
deallocated using "T::operato r delete".

§12.5/4 describes the detailed rules for which "operator delete" is called.

Now this implies that even though "operator delete" is a static function
it's accessed via some mechanism resembling a virtual method call, i.e.
in a C++ implementation that uses the vtable mechanism, via the vtable.
If it does, it involves a downcast and an upcast to get to
the right place.
The base class parts of an object are not allocated separately from
the object. The object including all its base class parts is allocated
in one chunk. If the object is of type T then "T::operato r new" is used
for allocation, and, if it has a virtual destructor, "T::operato r delete"
for deallocation.
Beyond this, I am having a fit trying to figure out, I guess, "delete
visibility" for polymorphic objects. Delete is always static, so it seems
that the class actually being "deleted" needs to have the class with the
correct delete method as a base class. But what if you wind up with
multiple base classes with their own delete operators?
I'm not 100% sure whether that is allowed, although I do think so, but
it does seem like a recipe for disaster. Presumably there's some reason
for these operators being defined. So instead of inheritance consider
encapsulation.
[I have inherited code with a BUNCH of rocket science assembler level memory
management put together by a system architect who got his PhD in memory
strategies. He's gone, and now the new builds are not stable. My first
choice was to comment out ALL new/delete operators and just use the heap,
but the system won't stay in real time under load. I think the memory
management stuff works, but the C++ interface to it -- new and delete -- is
not safe. He was a memory and architect guru but maybe not a C++ guru. I
am no kind of guru, but I'm here on a saturday 2 weeks behind a release
schedule sweating bullets. HELP!!]

As another poster have written, good luck! ;-)