Why don't the dsp:: processors inherit from ProcessorBase?

Title says it all. I know they can be used with ProcessorWrapper perfectly fine since they have method signatures matching ProcessorBase without actually inheriting it, but why not just inherit from ProcessorBase for compile-time override safety? I’m guessing it was done to avoid vtable lookups, but since the overridden methods are pure virtual I’m (fairly) certain there wouldn’t be any anyway.

Is inheriting from ProcessorBase something we end users should be avoiding too?

(Pinging @IvanC via tagging)

EDIT: Answered my own question somewhat. ProcessorWrapper exists to conform a class to the ProcessorBase interface via static polymorphism. This is how all the factory processors appear to be used in practice. While I guess that’s handy, I still don’t really get why that route was chosen. Does it really make that huge of a difference performance wise vs. overriding a pure virtual method…?


The goal here was to make it possible to use template metaprogramming to build a graph out of processor objects, allowing the compiler to boil down the whole thing into a single inlined processing function, for much better performance than you’d get if it failed to be able to de-virtualise them for some reason.

Also, ideally the process function should be able to take any sample type, not just float or double - if you want to pass a vector of 13 doubles, or some other weird type, that should work and be inlinable by the compiler, which isn’t possible when you have to choose the parameter types for a virtual base class method.


I see, so the included processing functions are much more generalized to accept many different situations vs. ProcessorBase which accepts only one type (ProcessContextReplacing<float>). Which for folks like me writing my own simple processing functions works fine. Awesome, makes sense now thanks!

1 Like