|
One thing that's been a stumbling block to me in C++ is the tension between compile time polymorphism (or static polymorphism) and runtime polymorphism (or dynamic polymorphism).
Compile time polymorphism is done via templates; the decision about which type to use is decided when the program is compiled. Runtime polymorphism is done via virtual methods. The decision about which type to use is decided as the program is running.
These two approaches seem to be orthagonal(?) to each other.
I was (re)watching a video[^] on YouTube. It's a presentation by Sean Parent of Adobe. He's "a principal scientist at Adobe Systems and engineering manager of the Adobe Software Technology Lab." The entire video is interesting. He talks about generic programming and also designing software components that are connected together to form a directed acyclic graph.
There's a point in the video that has intrigued me ever since I first saw it. There's a bullet point (which unfortunately Sean doesn't elaborate on) that says: "Extend generic programming to apply to runtime polymorphism."
Ah, this seems to be getting at that tension I mentioned early between compile time and runtime polymorphism.
So I did some googling and found an interesting paper[^] describing a design pattern called External Polymorphism. This seems to provide a structure for merging generic programming with runtime polymorphism.
I won't describe the pattern, but I can describe how I applied it to writing VST plugins. The following assumes a basic knowledge of the VST v2.4 SDK, but hopefully you'll be able to follow along without being familiar with it.
Say you have a bunch of objects that you've created on the heap, e.g. you created them in createEffectInstance and then passed them to other objects that interact with them. The lifetime of these objects is the same as that of the plugin. You'd like a reuseable, generic way to dispose of them. Here's an approach using External Polymorphism:
class DisposableInterface
{
public:
virtual ~DisposableInterface()
{
}
};
template<class T>
class Disposable : public DisposableInterface
{
public:
Disposable(T *target)
{
this->target = target;
}
~Disposable()
{
delete target;
}
private:
T *target;
};
Ok, in our base Plugin class we have a method for passing any object that will be garbage collected when the Plugin itself is destroyed:
class PluginBase : public AudioEffectX
{
public:
virtual ~PluginBase()
{
std::list<DisposableInterface *>::iterator it;
for(it = objects.begin(); it != objects.end(); it++)
{
delete *it;
}
}
template<class T>
void AddToGarbageCollector(T *object)
{
objects.push_back(new Disposable<T>(object));
}
};
AudioEffect *createEffectInstance(audioMasterCallback audioMaster)
{
Plugin *plugin = new MyPlugin();
Lfo *lfo = new Lfo();
AdsrEnvelope *env = new AdsrEnvelope();
Oscillator *osc = new Oscillator(lfo, env);
plugin->AddToGarbageCollector(lfo);
plugin->AddToGarbageCollector(env);
plugin->AddtoGarbageCollector(osc);
return plugin;
}
Now, you may never need this kind of memory management, so don't get tripped up on the example. The main point is that we can treat "concrete types" polymorphically. We don't have to make sure that they implement a particular base class.
I'm not recommending using this approach to replace virtual methods in all classes, but I prefer to write my low-level classes without them. And I occasionally need to iterate over a collection of these concrete objects for one reason or another, e.g. updating the sample rate or whatever. As long as they meet the requirements of the algorithm that's being applied to them, e.g. provide a method or operators with specific signatures, this technique can be applied to fascilitate this.
Like...
class PluginBase : public AudioEffectX
{
public:
template<class T>
void AddTempoTarget(T *object)
{
tempoTargets.push_back(new TempoTarget(object));
}
};
Then when the tempo changes, we could do this:
std::list<TempoTargetInterface *>::iterator it;
for(it = tempoTargets.begin(); it != tempoTargets.end(); it++)
{
(*it)->Tempo(newTempo);
}
As long as the target objects have a method called Tempo that takes a double (or whatever) they can be notified when the tempo changes, they don't have to inherit from a specific class.
Anyway, this was a puzzle that had been in the back of my mind ever since I became interested in generic programming, and especially after seeing that bullet point in Sean's video. Just something else to add to my bag of tricks.
|
|
|
|