Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > delete, polymorphism, and multiple inheritence

Reply
Thread Tools

delete, polymorphism, and multiple inheritence

 
 
Ian McBride
Guest
Posts: n/a
 
      07-19-2003
(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!!]



 
Reply With Quote
 
 
 
 
Buster Copley
Guest
Posts: n/a
 
      07-19-2003
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.

 
Reply With Quote
 
 
 
 
Alf P. Steinbach
Guest
Posts: n/a
 
      07-19-2003
On Sat, 19 Jul 2003 13:14:03 -0400, "Ian McBride" <(E-Mail Removed)> 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:perator 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:perator new" is used
for allocation, and, if it has a virtual destructor, "T:perator 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!

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Multiple Inheritence Neelesh Bodas C++ 5 01-03-2006 08:09 PM
Multiple Inheritence and data attributes Derek Basch Python 1 05-06-2005 09:49 PM
multiple inheritence shruti via JavaKB.com Java 11 04-03-2005 02:25 PM
multiple inheritence shruti tiwari via JavaKB.com Java 3 04-01-2005 12:58 PM
multiple inheritence question Michael C. Starkie C++ 4 08-14-2003 02:36 PM



Advertisments