Hi Jules,
while scrolling through your commit stream, I noticed you changed the handling of Identifier parameters to pass by Reference.
Why was this necessary and do you recommend doing the same thing in our user code?
I am currently writing some stuff that heavily pushes Identifiers around but I did it the old way (like the almighty master told us to), and now I am afraid of a "search and replace" orgy when I update JUCE to the newest tip :)
I liked the by-value style too!
But..
When I first wrote the Identifier class, it was very light to copy - basically just a wrapper around a const char* - and the lifetime of the string was handled by a string pool. So pass-by-value was the most efficient way to do it.
I had to change the class so that it now contains a String instead, and any copying adds the overhead of atomic ref-counting. That's usually OK but we hit some performance problems in heavily-used ValueTrees and NamedValueSets that showed that using it as a pass-by-value type can be a significant problem in some situations. Changing it to const refs made a massive difference to our app here.
So yes - the current advice is to use const ref& when passing them as parameters in performance-critical code. In non-performance intensive code, don't worry about it!
Why the change from the string pool implementation?
Because the string pools could never garbage-collect unused strings, because they weren't ref-counted. That's fine if you use a finite set of identifiers, but we had situations where dynamically generated ones would keep growing the pools.
