C++14, C++17 and forward about magnum HOT 4 OPEN

@mosra C++20 mentioned, yeah 😛

from magnum.

There are embedded Linux platforms that don't have the option to use Clang instead of GCC and I have important clients on these -- can't just drop GCC support :) Besides that, at the moment it's possible to just use a stock Ubuntu with whatever GCC is installed on it and that's a nice "plug and play" feature I wouldn't want to lose.

I'll introduce support for C++14 and 17 features on an opt-in basis (for example enabling constexpr for more APIs) -- if you enable the C++14/17 standard via a compiler switch, they'll be there, otherwise not. To avoid maintenance nightmares, these will affect mainly the public-facing API, the internal code will stay on C++11 as long as it's feasible.

from magnum.

MSVC 2014 (?) -- they implement both C++11 and C++14 simultaneously with varying success, so let's hope it is supported well enough in the next release

From experience with working with MSVC 2013, the C++11 support they added (at least std::thread & std::unique_ptr) was OK, but it took a few patch releases to get it fully working. So there's that added delay too...

from magnum.

Hmm what about to move everything to Clang (not GCC or MSVC) ? They are doing really good work, also with support for Windows platform: https://clang.llvm.org/docs/MSVCCompatibility.html
Also on Linux there are tests to compile the Linux kernel with Clang compiler, Debian tries to re-compile all packages, Android uses also Clang (android/ndk#26)...

Also MSVC installer actually have an option to install Clang with it (old version 6.0 i think).

I think, just wait only 5 months or 1 year and Clang will take over the MSVC compiler (I seen tweets that Clang actually started destroying MSVC compiler - they just moved from it) :D

I'm talking here about MSVC because is the most problematic platform. On Linux and Mac users can use Clang without any problems, but on Windows only MSVC or Cygwin-like stuff.

from magnum.