Pure Virtual Functions in ValueTree::Listener

There’s a lot of pure virtual functions in ValueTree::Listener:

Is there a reason for this, because many times I just want to listen to one of these functions and it clutters the interface.



Well, I’ve often favoured pure virtuals for things like this because it means that when we change the interface, it forces people to update their code, and they won’t silently get a problem where their methods don’t get called an more.

(Of course if only we could trust everyone to always add ‘override’ to all their code, then we wouldn’t need that precaution!)

You can’t workaround all flaws users might introduce. You even don’t know how users will use your code. You don’t know if marking those methods pure is helping or distracting them.
I prefer a clean interface than “helping” me to program correctly. Thats solely my part and its easier with a clean interface that doesn’t force me to implement unnecessary stuff just because some users may be too lazy to add ‘overwrite’. This might not even be real problem and use case. This is just “in case”.

And in the case you change the interface I would have to change all the dummies. What kind of tradeoff is that?

You can’t foresee all flaws. Your responsibility is a clean, easy to use interface and not teaching the user to program. By marking those methods pure you add a lot of work for the user ending up in cluttered code, which for no additional functionality adds maintainance effort. The purpose of those empty methods is not self explanatory, and if someone take over that code, she needs to read across a lot of unnecessary stuff asking for its reason.


Well the trade-off is that your code doesn’t continue to compile with slightly altered behaviour that could break your products without you noticing!

Thats the preposition of my earlier post. I already got the point.
Its about rethinking if this is the right approach and wether it makes sense to force users in a certain way to avoid few of the variety of possible programming mistakes.

I share @raketa’s point of view: it’s up to the client code to follow the best practices and add those “override” keywords in order not to have surprises in case the interface changes.

If they get problems because of that, that’ll teach them a lesson that will stick, pretty much like when one learns the hard way that RAII is preferred to decoupled new and delete.


A little bit OT but maybe not:
when I create a new class in projucer, it adds default methods for a Component. I always wished, I could supply a parent class and get a skeleton with all pure virtual functions to be filled (and carrying the override keyword)…
That way you don’t have to look up all methods, what you have to implement. So it wouldn’t hurt so much to add e.g. all callbacks to a ValueTreeListener. Also very handy on AudioProcessor, when new callbacks were introduced.

But I also think adding empty functions, just it’s pure virtual in the base class, desn’t make your own code more readable.
tl;dr: +1 for raketa and yfede…