Creating arrays/vectors of components. Copy/Move semantics

[ImJimmi]

I’m sure there’s some cases where the STL is far better, and I’ve never really tested it myself. All I know is that there have been attempts to replace juce::Array with std::vector but it was found to be significantly slower for some crucial tasks.

There’s a few comments about it in this thread from this comment onwards:

OS X 10.6 support survey

I don’t really think we’d want to actually remove any of the old containers, certainly not for a few years. Even if we stop using them ourselves, we don’t want to break user’s builds unnecessarily. And yes, some of them (especially OwnedArray) do things that are lacking from the std library. You could argue that Array could be replaced by std::vector (which correctly handles a few things that Array couldn’t do because it needed to work with old compilers), and OwnedArray with std::vectorstd::un…

TLDR, juce::Path is one of the cases where replacing juce::Array with std::vector is much slower.

Having said that, there’s also this comment from Jules recommending the use of STL containers where possible, although that’s older than the previous thread so perhaps the performance difference wasn’t known at the time:

Juce classes vrs c++ std

TL;DR for this question: Yes, JUCE was written way back in the old days, when the standard containers were really unsatisfactory, and most libraries rolled their own container classes. Since C++11 became a thing, our advice is that if you can use the new standard, then you should prefer things like std::unique_ptr, std::vector, std::array, etc. The JUCE equivalent classes do their best given the contraints of c++98, and some people will probably always prefer them for various reasons, but the …