Destructor of AudioProcessorEditor should be virtual?

Audio Plugins
1

In order to simplify GUI design maintenance, I am using the following inheritance scheme for my plugin’s editor:

AudioProcessorEditor
   -> MyEditorComponent
      -> MyEditor

MyEditorComponent is maintained with the Jucer and happens to change rather frequently, while MyEditor contains quite a lot of code that I didn’t want to squeeze in between the []…[/] special comments of the Jucer-generated component. I found this way of putting the GUI in between AudioProcessorEditor and the actual code implementation very easy to maintain.

I might bemissing something, but I wonder whether the destructor of AudioProcessorEditor should better be virtual (same goes for the derived Juve generated component, btw), so both MyEditorComponent and MyEditor will be decomposed correctly on destruction. Even if one does not further derive from the Jucer-generated component, there remains the same situation.

2

huh…? It inherits from Component, so obviously already has a virtual destructor (??)

3

Ah sorry. I didn’t know the virtual status is retained throughout the hierarchy, regardless whether derived classes do declare it.

After a few months with C++ I am absolutely fine with everything except the quirky mechanics of the inheritance scheme and only half-baken polymorphism, which both seem like a minefield to me. I also find it very hard to code without closures (a simple three-liner turns into half a page of redundant and repetitive code), although I really love multiple inheritance.

EDIT: You know, something like this would be great:

bool whatever ( AnyClass& any ) { collection.eachDo ( (ObjectClass& each) { if ( !each.doSomething (any) ) return false; else each.doSomethingElse (any); } ); return true; }

4

http://www.boost.org/doc/libs/1_39_0/doc/html/foreach.html

5

Well, when everyone’s finally using c++0x, the language will provide foreach, closures, etc. Until then, it’s pretty cumbersome to try to emulate that kind of functionality, so I’ve avoided it.

6

Well, foreach is only one example of many, many uses. In my example above, eachDo() could be implemented differently throughout the class hierarchy. It could work for arrays, hashmaps, sets, strings, streams, etc.

My other project implements around three thousand classes, many of them in deep inheritance trees. Without closures, generic algorithms and excessive polymorphism, I would be unable to handle the complexity.

Clean decision.