C++14, C++17 and forward

[mosra]

This used to be a list of exciting new features present in newer C++ standards to look forward to. Now it's rather a list of non-insance C++14+ features that could be worth backporting to C++11.

C++14

• Support in the CORRADE_CXX_STANDARD CMake property and preprocessor macro
• Exposing C++14 constexpr via CORRADE_CONSTEXPR14 -- mosra/corrade@9cf91f0
• Backport std::integer_sequence optimizations -- mosra/corrade@0b82814
  • Clang implements it directly, use that as well? does it bring anything useful?
• Make use of sized deallocation
  • All array deleters are already prepared for this, as they get the length as well

Compiler support

• GCC 4.9 (released on April 22 2014) is probably the first GCC with considerable chunk of C++14 features implemented (4.8 not so much)
• Clang 3.4 has full C++14 support (on the other hand, 3.3 has nearly nothing from it)
• MSVC 2015 (?) -- 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

For all compilers we need to wait until their usage is similar to GCC 4.7 and Clang 3.2 just now (May 2014). We'll see after dropping GCC 4.7 support (#274).

Good resources about compiler support are at http://www.g-truc.net/project-0036.html for major vendors and also at http://en.cppreference.com/w/cpp/compiler_support for the other.

Features

• relaxed constexpr -- it would be finally possible to implement compile-time MurmurHash without the code being write-only, also many math functions will benefit from that (so the user doesn't need to precompute math operations in tight loops by hand, but can just slap constexpr specifier on the result and be done with it). Experimental stuff already available in cpp14 branch.
• variable templates (i.e. Pi<float>) -- not sure about the usage, the current way with enums and functions ensures that the value is not exposed as any linkable symbol (you can't take address of enum or function result), which in my opinion is exactly what we want for constants -- to be always on stack and not referenced through some slow indirection. Also this (from API perspective) is easily doable using template aliases, am I missing something?
• binary literals -- probably not so useful in library code, as for flags 1 << n is much more readable
• digit separators -- also rather in user code than in library code
• [[deprecated]] attribute might help with getting rid of the ugly CORRADE_DEPRECATED() macro and its compiler-specific quirks actually no, the attribute can be used for enums and namespaces only since C++17, so the macro is going to stay
• make use of feature test macros for C++14+ features instead of relying on STL/compiler version checks hahahah you wish, as long as compilers are buggy this is only a wet dream

STL features

The issue is that these won't be advertised in compiler release changelogs and thus we might have some very nasty surprises (e.g. std::map::emplace() didn't exist until GCC 4.8).

• std::float32_t and std::float64_t instead of float and double, just to be consistent with strict type definitions we already have for integers this proposal disappeared somehow
• std::enable_if_t<...> instead of typename std::enable_if<...>::type (and similar) -- 13 characters shorter, will help a lot in implementation details of generic classes not worth the backwards compatibility pain
• std::make_unique() for much less verbose std::unique_ptr construction nope, making my own thing
• std::exchange() utility function instead of the following fugly piece of code -- could also implement my own, and wasn't all that essential after all
• std::string literals, I hope they help with avoiding the copy and allocation on construction, otherwise I can't think of any other use case (apart from proper '\0' handling) no, they don't, gah; having my own StringView (and string literals) nowadays

C++17

• Support in the CORRADE_CXX_STANDARD CMake property and preprocessor macro
• Expose aligned allocation and std::aligned_alloc(), fallback to posix_memalign() on pre-C++17 -- mosra/corrade@c095551
  • Use it implicitly in Array / ArrayTuple if dealing with over-aligned types
• attributes ([[deprecated]]!) for namespaces, enums and enum values (for enums this somehow already works in Clang C++11) -- currently used in CORRADE_DEPRECATED_ENUM() macro
• compatibility of Containers::Optional with std::optional
• compatibility of Containers::StringView with std::string_view -- mosra/corrade@cf0bd1f
• Opt-in support for destructuring bindings -- std::tuple_size / tuple_element specializations for Corrade containers corrade#157

Compiler support

• MSVC 2015 Update 4+, Clang 3.8+, GCC 6+?

Features

• template argument deduction for class templates -- obsoletes all make*() helpers -- thanks to our naming scheme, the "make" helpers are not any longer than using the class name directly (pointer() vs Pointer), so this is a non-issue
• static_assert() without message -- useful for user code, not library code, there we should provide a message always

STL features

• std::observer_ptr instead of raw pointers sorry, bad joke
• std::is_integral_v<...> instead of std::is_integral<...>::value (and similar) - 5 characters shorter (slower compile times?) not worth the backwards compatibility pain
• std::void_t (N3911) has an interesting example to simplify CORRADE_HAS_TYPE() macro
• constructing std::tuple with just {} -- I basically banned std::tuple from the codebase since
• uninitialized_value_construct() etc. as more optimal alternatives to placement-new-in-a-loop in Containers::Array NoInit and other versions (but one needs <memory> for that, ugh)
• finally a crossplatform filesystem handling to replace our own incompletely tested Corrade::Utility::Directory I doubt it will ever catch up with my requirements, also there's a very small intersection between what I need (isSandboxed()) vs what it provides (operator/ for concatenating directories, wtf)

C++20

• Support in the CORRADE_CXX_STANDARD CMake property and preprocessor macro
• Compatibility of Containers::ArrayView with std::span
• std::source_location, but on C++11-level compilers -- Source location in Debug corrade#55, mosra/corrade@d28fe79

Features

• expansion statements -- explicit loop unrolling by a compiler, yay!
• explicit(bool)
• __VA_OPT__, like __VA_ARGS__, but allowed to be empty
• delete operator that's executed before a destructor -- since Clang 6, could allow nice optimizations
• getting feedback about how many bytes got actually allocated by new to avoid unnecessary reallocations
• modules to replace the old #include system -- though probably DOA, not speeding up anything
• using enum
• constinit keyword -- could allow GL::defaultFramebuffer to be initialized using a constant expression, but then used as a mutable instance?
• consteval functions -- like constexpr, but enforcing that the function call is actually done at compile time (instead of just making it possible)
  • useful for making APIs both constexpr and SIMD-able -- Add constexpr to Vector{2,3,4} and Vector<N, T> #597
• ability to change the active member of an union in a constexpr context

STL features

• use std::endian instead of propagating the info from CMake (or just figure that out from platform-specific macros)
• make use of std::is_constant_evaluated() ... why this wasn't there since c++11?!
  • Using the builtin instead, even on pre-C++20 -- Containers: add StringView overload for known sizes corrade#155
• <version>
• this paper could get rid of (some) strict aliasing issues?
• std::format(), based on the implementation from the author of fmtlib. Utility::format() is already much faster than fmtlib at compile time and could be also faster at runtime, once I get my hands on it.

C++23

Features

• #elifdef / #elifndef; I wonder when it will make sense to upgrade to C++23 just to get these (or maybe they'll be usable even wiithout picking the full standard?)
• operator[] where I can use ,, finally
  • Implement that in StridedArrayView, and an operator() fallback until then
  • Implement that in Matrix, and an operator() fallback until then

STL features

• portable stack trace retrieval in <stacktrace>

Not yet

• Compatibility of StridedArrayView with std::mdspan
• variable-length arrays, which will avoid heap allocations in some cases. Main use case is converting std::initializer_list<T> parameters to GLuint[] when passing them to glBindTextures(), glShaderSource() and other "multi" functions. Not part of C++14, but available in GCC since forever as GNU extension and it is made "official" in 4.9. Clang originally chose to not implement this at all, so it's not available in it yet. On the other hand, if I'm lucky I might be able to work around the allocation with some implicit conversions and then pass the std::initializer_list data directly. too slow, error prone and dangerous, won't use that ever (case in point: Linux kernel removed them all for better stability)
• std::vector::release() and an "acquire" counterpart -- rejected from C++17, nobody cared since then, and I have switched to my own containers anyway

[waddlesplash]

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...

[TheAifam5]

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.

[mosra]

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.

[ttnghia]

@mosra C++20 mentioned, yeah 😛

[mosra]

Closing as most of the checklist above is implemented. The remaining bits are tracked in various project cards, in particular the Corrade / Containers project, features from newer C++ standards are going to be added on an as-needed / as-requested basis.