Hi,
why is C++14 the default language option for new projects?
And can I use C++17 without hesitation?
I’m on Win/VS2019.
1 Like
Most of C++17 should be supported in VS2019. Check the table below for more specific information.
Juce itself does not require a newer C++ standard at the moment. You are free to use newer standards in your own code, but if you are doing cross platform code for a range of old and new operating systems, you might want to check the newer standards (including the C++ standard library) are supported on each version of each platform you are targeting. AFAIK this is not a problem on Windows, as the C++ runtimes can be used via dynamic or static linking, but it can be a problem on macOs and Linux as those traditionally rely on the C and C++ runtimes installed system wide, and those are often old versions.
2 Likes
Good to know. Since i’m targeting Windows and macOS, i need to know, which c++ features/version is supported on current macOS-versions. There seems to be very little information available on this topic, because Apple themself don’t seem to communicate it externally. Is this correct? I found this discussion on reddit about this topic https://www.reddit.com/r/cpp/comments/ao4jqr/i_created_an_xcode_compatibility_table_for/.
Does anybody know the current “state” of C++17 in current macOS-versions?
An example of this that has bitten me recently: std::visit, along with anything else that might throw std::bad_variant_access, cannot be used when targeting versions of macOS below 10.13.
For the most part, as long as your “deployment target” is set to the lowest macOS version you want to support, you should get build errors if you try to use a feature that isn’t supported on that version. Also, all the ‘core language’ features of C++17 should work absolutely fine on all platforms, and incompatibilities should only affect standard library features.
1 Like
Have you ever investigated the possibility of building the needed C++ standard library parts yourself and not relying on the library provided by Apple on the system? Is that possible/advisable? (I bumped into the same issue with exceptions related to std::variant…)
Well, in the case of variant, the entire feature can be implemented using only headers, and it’s easy to find header-only implementations on github that can be dropped into a juce module, wrapped in a namespace like stdx. I’ve used this approach in the past with optional, and when the real std::optional became available on all platforms I just removed the module and used sed to replace every stdx:: with std::.
I think, as long as you choose an implementation that tries to implement the standard as closely as possible, this approach works well.
I’m not on a mac right now but iirc the std::variant stuff was all in <experimental/variant> and the std::experimental namespace, pre-mojave. I had a few projects where re-exporting the appropriate headers/templates worked, but I don’t remember if there were any API issues.
I was able to do some hackery with the header files to get purely header based things to compile in Xcode 9, but there are some parts in the C++ standard library that would need to be built from .cpp files too. Apple provides ready built binaries for those in the system install, but those are out of date in the older systems. (I am running 10.13 myself.) So I am interested in the scenario where those parts of the standard library that need to be built from .cpp files, would be compiled and linked by the application/plugin developer instead of using the system provided libraries…
just played around with std::execution in VS2019, which is actually extremely great, but it looks like it’s not available in Xcode 
I just add comment on this thread since I didn’t find any answer to my current naive question.
One of my next moves would be to use C++ 17 but I’m not sure about the platform compatibilities guarantees.
Is it safe and enough to upgrade to C++17 and target the lowest target I want on Xcode / Visual Studio ?
If the project build correctly, will I be sure it will work perfectly on the lowest target and higher?
For exemple I’ve heard that std::filesystem will be only available on macOS 10.15 and higher. But since I don’t plan to use it, it won’t be an issue right?
We are successfully using C++ 20, targeting a minimum macOS deployment target of 10.9 for some products at the moment and it works if you only use the features supported by Apple Clang and supported by the deployment target. There are e.g. some newer std library exception types that are not supported for older deployment targets, so as soon as you start using a std library function that could potentially throw an exception like that, you’ll run into a compile error if your deployment target is to low. I encountered this e.g. with std::variant. If language features are not supported at all by the compiler you’ll also get a compiler error – although in contrast to C++20, C++17 is quite well supported to my knowledge. This chart gives you a more detailed overview: C++ compiler support - cppreference.com
Long story short: Set your deployment target right and then you are safe. If it compiles, it will run 
8 Likes
