OS X 10.6 support survey


macOS version, we’re still supporting 10.7.


Please reconsider the CriticalSection thing. I am not that sure that implementation wise std::mutex, or rather std::recursive_mutex which you should be replacing CriticalSection with, is that great on all platforms. For example in Microsoft’s C++ standard library implementation there’s an unbelievable amount of wrapping code around what probably amounts to just using the Windows native CriticalSection object. The existing JUCE implementation of CriticalSection seems far more cleaner.


Not to mention that JUCE will be stuck supporting C++11 for now.


The DSP module already requires C++14.


We have our own internal DSP modules so it’s unlikely that we will be using that yet. We won’t support 10.7 forever but even with make_unique I still find it less intuitive than ScopedPointer, not that I’m suggesting the JUCE team shouldn’t switch to unique_ptr, although I am suggesting they stick to C++ 11 at least for now.


I did use to feel this way but as you say, a make_unique is a simple addition, +1 for juce::make_unique.

However, after reading this article I changed my mind: https://herbsutter.com/2012/06/21/reader-qa-why-dont-modern-smart-pointers-implicitly-convert-to/

After using it for a bit I realised I don’t actually use get all that often and in the places I do it actually makes code more readable.

Also operator bool() is good.


Seems like a good argument, and I do tend to say explicit is better than implicit. Also someone has just pointed out to me that you can do this to assign a unique_ptr uniquePtr.reset (new MyObject());, however make_unique is still safer so I still vote for juce::make_unique().


I was thinking more about C++14 support and I think we have at least two 3rd party companies we work with that still require us to stick with C++11 or support 10.7.


Over the past few months we’ve slowly been migrating ScopedPointer use in JUCE to use the same interface as std::unique_ptr and it hasn’t resulted in an explosion of boilerplate.

ScopedPointer will be removed first, followed by Atomic, followed by (potentially) CriticalSection - with these tasks ordered by increasing difficulty. Of course we will proceed with caution, and if we come across anything unexpected or a performance regression then we’ll reevaluate.


Especially for CriticalSection, some performance measurements should be done before replacing them in the repo.


You can build on macOS 10.11+, using C++14 (Xcode 7.3.1), while targeting 10.7.


Surely that’s only true if you are careful to use syntax changes only not library features - no?


CriticalSections on Windows are extremely fast as they’re initially only spin locks that require no context changes. Replacing them with a recursive mutex will make them a LOT slower.


are you planning on removing any other Juce tools, like OwnedArray, etc in favor of std:: (non)equivalents?


I highly highly doubt that would ever happen. JUCE’s containers make several important distinctions regarding memory management that work around the problems that make STL containers unsuitable for real-time use (i.e. guarantees on which calls will allocate/free memory).

Atomic and ScopedPointer are definitely on the chopping block as they’re nearly 1:1 redundant with std::atomic and std::unique_ptr, and as has been pointed out, are actual inferior in some ways.


An OwnedArray can be made up like:

std::vector<std::unique_ptr>> things;

But I have to adapt myself to the change before I can have an educated opinion, if that’s a good idea…


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::unique_ptr but std::vector was designed a long time ago and is a bit clunky to use IMHO.


yeah, you guys kinda nailed it with OwnedArray. that container is awesome.


I investigated replacing Array with std::vector some time ago. One good feature of Array that I couldn’t reproduce is that it uses realloc to change capacity, making it much faster in many dynamic contexts like graphics.


This is a really good point, actually. I once tried using std::vector as a replacement for the storage in Path, and it made the class unusably slow!