It's an euphemism to say that I'm frustrated by the impossibility I encounter of using C++ 11 on a daily base for my personal and professional projects.
For the case of libraries like GLM, the code must build on old enough compilers because users may rely on those compilers. Yes, I received multiple requests to support Barland C++ 5.5 compiler! It's also only with GLM 0.9.6.0, released in November 2014, that I felt confident enough to drop Visual C++ 2005 and 2008 support.
One way to work around this issue is to ask the users to use older versions of GLM if they want to use it on an old compilers. Obviously, this either mean back porting bug fixes or letting the users maintain the older release.
For the case of applications, they may relies on binaries that we don't have the source or binaries for the new compilers. Alternatively, the code base may be used on platforms which development tools are not updated anymore as it's often the case with consoles. It's clearly a complex nest which needs to be resolved per code base.
Finally, a last issue for adopting new C++11 features is simply our own ignorance of which feature is available on all the compilers we support. To resolve that problems, I made the followiong table listing all the C++ features and their support on Clang, GCC, ICC and Visual C++.
I have been looking for some information about the C++11 support in CUDA but there is just no good public information for that. In my opinion and from my experience with GLM, the static C++ language and library support in Cuda is largely behind even for the C++98 support.
Android is also a pretty difficult platform to support and I think the cause is the initial code debt of the early NDK releases which were in an horrible non conformant states with a library mess.
Jonathan Adamczewski made the following great charts from these data, showing how compilers have progressed over time, based on the compiler release dates.
Let's hope Microsoft will invest more in the C++ compiler to catch up!