delete, polymorphism, and multiple inheritence

**Buster Copley** · Jul 19 '05, 03:34 PM

Re: delete, polymorphism, and multiple inheritence

Ian McBride wrote:[color=blue]
> (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.[/color]

I don't know. It worked ten minutes ago... What does VC++ have to say
about the listing I posted?
[color=blue]
> 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?[/color]

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.
[color=blue]
> [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!!][/color]

Good luck.
Buster.

**Alf P. Steinbach** · Jul 19 '05, 03:34 PM

Re: delete, polymorphism, and multiple inheritence

On Sat, 19 Jul 2003 13:14:03 -0400, "Ian McBride" <ianmcbride2003 @yahoo.com> wrote:
[color=blue]
>(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?[/color]

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.

[color=blue]
>If it does, it involves a downcast and an upcast to get to
>the right place.[/color]

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.

[color=blue]
>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?[/color]

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.

[color=blue]
>[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!!][/color]

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

delete, polymorphism, and multiple inheritence

delete, polymorphism, and multiple inheritence

Comment

Comment