Hi Jules !
I have a request concerning the AudioProcessor class:
Would it be possible to make the getParameter method const (as I think it should be) so that I could call this from a const accessor ?
Thanx in advance !
yeesss… It should probably be const, though I’m always a bit reluctant to make virtual methods const in case people need to use it in a valid way that can’t be done if the method is const. I’ll have a think about it.
I’m digging this out, as I got the same issue after designing a neat template framework which expected all the get* methods from AudioProcessor to be const 
I understand that getters could sometimes be non-const, like in the case where it caches the values or something like that, but in such cases, isn’t it the responsibility of the lower level layer (the guy who decided to cache some stuff) to make his cache mutable and don’t bother its users?
Actually, I don’t really care with the const or non-const, all I ask for is some coherency to avoid writing special cases in my code: getName is const, getNumParameters is non-const, acceptsMidi is const, getProgramName is non-const, etc.
Yeah, I understand what you mean, but my thinking is that these methods are going to be overloaded by many, many different classes, but only called from very few places. So by making them non-const, it saves a lot of people the effort of adding mutable/const_casts to their implementations.
And the AudioProcessor class isn’t the kind of thing that I’d ever keep a const pointer to anyway… It’s inherently a multi-threaded, live object, so its state can’t be expected to actually remain constant. The virtual functions which are marked as const are the ones that I’d expect to really stay constant over its lifetime, which is why for example getName() is const, but getProgramName() isn’t (a program name could be changed by another thread at any moment).