Virtual destructors

[Parker]

Does Aurora support virtual destructors?

[Ionic Wind Support Team]

Destructors are by nature non-virtual as all base class destructors have to be called in reverse order of construction.

[Parker]

What I'm wanting to do is this:

Code Select Expand

interface Editor
{
    ...
    declare virtual _Editor( );
    ...
}

so that a CodeEditor, MenuEditor, and FormEditor all inherit from (or implement) the Editor interface, and can all be referred to as a generic Editor. In C++ if I make all of the methods virtual (including the destructor) I can easily delete an Editor pointer and the correct CodeEditor::~CodeEditor or whatever other destructor is there will be called.

How should I accomplish this then in Aurora? (for now I think I'm going to do a manual destruction, but if there is a better way I'd like to know about it) Thanks.

[Ionic Wind Support Team]

I'll have to think on it

Paul.

[Ionic Wind Support Team]

I'll see if I can have it working by Rev 2.  It will require a few changes.

[Parker]

Thanks.

[John S]

My wife complains that the kids and I, "virtually destroy the house on a daily basis".
But I don't think that's the same thing 

[Ionic Wind Support Team]

Nope not the same.  A virtual destructor is a feature of C++ (and probably other languages) that lets the programmer be lazy.  Not really ...  but I read that in an article 

Given a pointer to a base class, when NEW was used with a derived class, DELETE will properly call the derived classes destructor even though your only giving it the base class pointer.  Smoke and mirrors:

Code Select Expand


class base
{
     declare _base()
     {
           print("base destructor called");
     }
}

class derived : base
{
    declare _derived()
    {
         print("derived destructor called");
    }
}


Given the code above if you were to do:

base *b = new(derived, 1);
delete b;

Only the base class destructor is called since the delete function has no idea that the pointer actually has the address of anything other than 'base'. 

derived *b = new(derived,1);
delete b;

Both destructors get called and both lines are printed.

What parker wants is to be able to make the destructor virtual:

Code Select Expand


class base
{
     declare virtual _base()
     {
           print("base destructor called");
     }
}

class derived : base
{
    declare virtual _derived()
    {
         print("derived destructor called");
    }
}


So that when given that code doing:

base *b = new(derived, 1);
delete b;

both destructors get called.  The reason for which might not be apparent, but if you had a bunch of derived objects that all shared a common base class you could have a function that only uses that base class pointer as a parameter and it could safely delete all of the objects even though it has no idea what the derived classes are.

The name "virtual destructor" is actually wrong, since it doesn't follow what a normal virtual method does.  But I suppose the designers of C++ didn't want to use another keyword in their language.  Since we all know virtual methods share the same name in derived classes, but that is not so with destructors as each is named the same as the class, prepended with an underscore.  And using a virtual method means that only the last overriden one is called by the compiler, not all of them as in the case of a destructor method.

My implimentation might be "slightly" different.

[Parker]

C++ doesn't allow me to make the base class destructor pure, but with Aurora it's either all or none with an interface.

To John S:
I'm writing Editor classes, one will edit source files, one will edit forms, one will edit menus (maybe more). Since every child of the MDI Frame would derive from Editor (or implement it), I want to be able to call any editor window an Editor, and be able to call general functions on it (including delete) without worrying about what it is. My current solution is to have a close() method and an empty destructor, but it would be nice to be able to do it with virtual destructors.

There's a lot of C++ that's there to make it easier on the programmer.

My thought on how to accomplish it would be to insert a call to the base class destructor in the derived class destructor if it is virtual, so then

Code Select Expand

Derived::_Derived()
{
    print("Derived destructor");
}
becomes (assuming it's virtual)

Code Select Expand

Derived::_Derived()
{
    Base::_Base();
    print("Derived destructor");
}
which of course wouldn't happen if it inherited an interface, but this way long chains of inheritance aren't a pain to manage.