the same goes for XCode, some C++11 features require at least OSX compatibilty level 10.7, but 10.6 is still popular (i think 10% markert share)
Whenver you goint to replace it, would be nice to have a long transitional phase without deprecation, and an exact how-to the classes can be replaced
(scopedpointers should never be allocated on the stack, always on heap, ie member/function variables)
!? AFAIK Thousand of stacked ScopedPointers are used in the JUCE sources.
( https://github.com/julianstorer/JUCE/blob/master/modules/juce_core/xml/juce_XmlDocument.h#L44 ).
So, a slightly dated bump. Is the consensus that we shouldn’t use ScopedPointer<> and we should use std::make_unique<> or std::unique_ptr<> ? ScopedPointer<> syntax is so much nicer and easier to read, and also the documentation is soooo much friendlier.
ScopedPointer works great for me. I’ve started to use shared_ptr though when I need such a thing instead of the ReferenceCounted JUCE stuff. And I use the containers, generally, in preference to the JUCE ones except when I need to interface with the JUCE API (e.g. File::findChildFiles(Array…)).
It would be very helpful if JUCE’s API documentation would touch on this topic.
For example, Atomic's documentation could mention std::atomic and say something about differences.
Hypothetical (and probably false) documentations for example:
std::atomic is a standard class that does everything juce::Atomic does, but juce::Atomic is still available for backwards compatibility reasons)std::atomic exists since 2015, and that unlike juce::Atomic it supports boolean types, it has severe bugs (link to report) on Android and so juce::Atomic should be preferred.Note that the above statements are probably false, and just serve as examples to stuff that I’d wish the documentation would tell me had it been true…
Saying so in the documentation would be the case for a specific version of a specific implementation.
By default, you should know your tools, and that means the standard library of the compiler you are using, hence no need to add this in the documentation.
And preferably there should be a documented source for such things that you should know, so it would be good for it to be in the documentation.
You mean something like the C++ standard and the compiler documentation?
Does the C++ standard touch on the topic on when should you use the JUCE alternatives?
lol it sounds like ##c++ from Freenode IRC on here
