Just started to look into Juce Arrays and they seem quite complex. What would be the main reason to use them instead of std::vector in C++?
I was particuilary confused by the fact that the traditional assignment operators is not used:
At least the way I tried with an int array, like:
Array<int> arr;
...
arr.set(1, 7);
I would have expected: arr[1] = 7; to work but it didn’t. Is set the way to make assignments always in Juce Arrays? I find very little info or practial examples on how to use these arrays.
But that isn’t any different to std::vector, if you wanted to do vec[1] = 7; the vector would have to have a size of 2 before attempting that.
In any case, using std::vector is probably the more correct choice these days, unless you are extensively working with Juce APIs that actually expect you to use the juce::Array.
Sorry, I phrased the question a bit incomplete, the ‘…’ was meant like:
Array<int> arr;
...some stuff to add elements to the array...
arr.set(1, 7);
The actual question was if assignment in Juce arrays always are with an explicit set method and not like traditional for arrays: arr[index] = value_to_assign? Looking at the extensive Array documentation on docs.juce.com I’m not sure if I’ve grasped the concept fully. Besides the assignment question I’m particularly interested in if there’s an arraytype recommended for use inside processorblocks that would be a better choice than standard vectors.
I guess what’s confusing me is that there are things in the Juice API that I maybe not need, where I can use traditional C++, but I’m not sure if that will lead to problems further down on the road.
Yes, that’s how it is. operator[] reruns a read-only const reference. I tend to prefer std::vector
Depends a bit on what you actually want to do. If you are accessing pre allocated memory, all containers with continuous storage should probably be just fine, e.g. std::vector, juce::Array or juce::AudioBuffer. Changing the size of any of those containers during your processing callback is always a no-go since it performs heap allocations which you want to avoid during processing. The same goes for creating temporary arrays during processing, using any kind of heap based container should be avoided here, but the stack based std::array is a good option here in case the size is a compile time constant and it’s not too big to blow your stack with a stack overflow.
Thanks for the explanation. I realize I need to get a better grasp on these memory and realtime related aspects. Maybe Will Pirkles book is a good start?