OS X 10.6 support survey


OK I just hit another example of why juce::make_unique() would be really useful…

You can’t do this with unique_ptr without some kind of make_unique(), at least as far as I can tell.

if (ScopedPointer<XmlElement> state = deviceManager.createStateXml())
    // do something with the temporary XmlElement 


We’ve not yet introduced any features from the newer standard library, but we’ll do so shortly.


I’m doing this in a constructor for a shader renderer:

VertCosShader::VertCosShader(ShaderRenderer& renderer, float rate) :
    this->rate = rate;
    Random r;
    topColor = Colour((uint8)r.nextInt({10, 255}),
                      (uint8)r.nextInt({10, 255}),
                      (uint8)r.nextInt({10, 255}),
    botColor = Colour((uint8)r.nextInt({10, 255}),
                      (uint8)r.nextInt({10, 255}),
                      (uint8)r.nextInt({10, 255}),

it works rad! obviously, it assumes the file exists, tho…


I’m slow responding to this thread, but anyway:

I have a survey that a sizable proportion of my customers fill out. Right now, 10.6.8 is used by 1.53% of my users. To put things in perspective, OSX is about 70% of my users, and Windows is at 30%.

XP is at 0.51% of my users, if anyone cares, and Vista is at 0.08%.


This will be a nightmare for me… my projects make heavy use of ScopedPointer, so unless I write my own wrapper class I can see much unforeseen code maintenance on the horizon :frowning:


Like I said above, we won’t remove ScopedPointer any time soon. We’ll stop using it ourselves and encourage you to stop too, but there’d be no sense in breaking anyone’s builds by removing it.


How about Atomic?
Better to use std::atomic instead?

Thank you.




Since removing 10.6 support Atomic is just a thin wrapper around std::atomic anyway. Using the latter directly gives you much more control over how you interact with C++'s memory model.


Is there any way for you guys to just add the features ScopedPointer is missing that std::unique_ptr has? std::unique_ptr’s usage pattern is just ugly:

addAndMakeVisible( mySpecialObjectInAScopedPointer = new SpecialObject(params) ); 
addAndMakeVisible( *(mySpecialObjectAsAUniquePtr = std::make_unique<SpecialObject>(params)) );

I get that you guys wrote ScopedPointer back when std c++ didn’t have a lot of tools, but as a few other people have mentioned in this thread, it’s often easier to use than std::unique_ptr<>.
What all can std::unique_ptr<> do that ScopedPointer can’t?


The good thing about std::unique_ptr is that it deliberately isn’t as easy to use as ScopedPointer, and that stops people making mistakes with it.

Obviously feel free to carry on using ScopedPointer if you want to - we won’t remove it any time soon. But the C++ committee put a lot of thought into the design of unique_ptr, and we recommend that you use it if you can.


Yes, there’s really not that much difference in the syntax and I’ve personally been saved several times by using the the std smart pointers. As Jules says, they just don’t allow you to do dangerous things.

I spoke about some of these in my ADC 2016 talk. No video unfortunately but the relevant slides are here from #33 https://github.com/drowaudio/presentations/blob/master/ADC%202016%20-%20Using%20Modern%20C%2B%2B%20to%20Improve%20Code%20Clarity/Using%20Modern%20C%2B%2B%20to%20Improve%20Code%20Clarity.pdf


a matter of taste, but perhaps more readable this way:

mySpecialObject.reset (new SpecialObject (params));
addAndMakeVisible (mySpecialObject.get());