> lack of thread local storage is not an issue
We've had it since C++11. http://en.cppreference.com/w/cpp/language/storage_duration
We've had it since C++11. http://en.cppreference.com/w/cpp/language/storage_duration
Note clang is not the only variable here. You need support from the dynamic linker.
Edit: some googling suggests they may have added this support last year with some caveats.
https://android.googlesource.com/platform/ndk/+/master/docs/...
You can already use clang 5.0 on the NDK, so even early C++17 support is possible. I don't know about TLS support.
The NDK is only there for high performance graphics (vulkan), realtime áudio, SIMD and bringing native libraries from other platforms.
So apparently their motivation is that devs should touch the NDK as little as possible.
There plenty of apps that could really use a well-supported NDK. Games and audio apps for a start.
"ARCore works with Java/OpenGL, Unity and Unreal and focuses on three things:"
https://android-developers.googleblog.com/2017/08/arcore-aug...
Which makes quite clear that even in AR, the role of the NDK is to support Java, Unity and Unreal applications, not to be used alone.
I am fine with it, given the security issues with the native code so we should actually minimize its use, I just would like they would provide better tooling to call framework APIs instead of forcing everyone to write JNI wrappers by themselves.
So they are still using C as a lingua franca for some low-level parts of the system. But without putting much effort into improving the C toolchain.
I'm not very familiar with Unreal but I understand it's a C++ library, so it seems like that would benefit from a solid C++ toolchain too.