I found a potential problem with the AudioProcessor implementation (and other classes probably as well);
it’s nothing serious per se, and I guess most compilers won’t even issue a warning, but nevertheless there is a
violation of the ISO C++ standard present.
In the processBlock() method, both parameters are references.
However, the ISO C++ standard explicitly makes using a reference argument to a function (and class method) as the first parameter illegal.
As I said, this may not even issue a warning on most compilers, but nevertheless it might be problematic in the future,
especially since the gcc is known for suddenly not accepting code anymore in violation of standards even in minor version upgrades;
thus, even if this is not an issue today, it might become one further down the road.
So I thought I better make that problem known and give jules time to consider the fact before suddenly compilers complain and break…
Eh? I’ve never heard of that one before…! Can you give a link to an actual description of this rule?
(And are you sure you’re not getting confused with rules about functions that take a variable number of args? There are certainly problems in those cases if you try to pass a reference as its first parameter)
Yes; I checked again after posting, and had to find out that the source I was using to base this on (printed media) was citing an incorrect part of the ANSI ISO C++ standard;
instead of citing section 8.3 (reference variables) it was citing section 18.7.3 (variable argument lists).
thus it was citing correct specification in the wrong context, and this also renders my finding bogus.
However, I personally would prefer implementing processBlock() with pointers rather than references -
in the specific application context I’m working on right now, and which triggered this whole thing, I have had a really hard time
encapsulating AudioProcessor, AudioBuffer and MidiBuffer instances in a ThreadPoolJob derivation and make it work correctly
just due to the fact that processBlock() expects passing by reference and is receiving by reference…
if it all were pointers I wouldn’t have had to look up on how to pass references to member variables by argument initialisation lists of constructors…
simply put, it would have saved me a whole day of research into an obscure C+±only and seldomnly used mechanism…
anyway, I hope I solved it, I’ll see when it compiles and works.
Sorry for the alert, anyway.
I don’t really understand what you’re talking about there… If you have a pointer and want to pass it as a reference, you just stick a * in front of it!
The arguments are references because that makes it clear that:
- The method expects to get a valid object, not a null pointer
- The method will not store a copy of the pointer anywhere
- The method will not take ownership of the object
It’s basic good practice in c++ to always use a reference unless you need to use a pointer.
Sorry for the delay…
In the thread context, I need to store the reference to the object so I can execute the Job times and times again after setting them up once;
hence the use of pointers would have been more beneficial here, but as I said, that’s just something that would have been nicer to have…
not impossible to work with the references.
I don’t fully understand what you’re saying about jobs (?) but you can’t store a reference to that object! The object is only valid for the duration of the method call! That’s why a reference is more appropriate than a pointer!
I know, that’s why it’d be so much less painful if it were pointers passed around, since I could then just pass those around instead of having to reference and dereference several times per frame…
What I’m doing is inside the main audio thread I examine which plugin instances can be chained up and ran in parallel, then attach these to a Job and re-use the Jobs every frame as long as the graph
doesn’t change… had to do that since Juce audio processing implementation on the host side of things doesn’t support mutlithreading itself.