The first beta of the .NET Framework arrived in 2000. As I look back at the decade following its unveiling, I cannot help but think of it as the first dark age of C++. Following on the success of Java, Microsoft likewise chose to distance itself from its strong roots in C and C++. The mighty developer division embraced managed code and worked tirelessly to build incredible tooling for C#. For a time the Visual C++ team tried to play catch-up with not one but two different language extensions for the Common Language Runtime (CLR), but they quickly realized that they were the unwelcome guest at the party. Thankfully, they returned to their roots in native code and so began the C++ renaissance championed by the likes of Charles Torre and others. This eventually culminated in amazing achievements such as the Concurrency Runtime, C++11 and dramatic improvements to the Visual C++ C Runtime (CRT) and Standard Template Library.
Just over ten years following the arrival of .NET, Microsoft announced Windows 8 and the new Windows Runtime. While .NET had arguably succeeded splendidly on the server, it always had an uneasy relationship to the Windows client mainly due to poor performance and the lack of a universal UI framework. With the advent of smaller devices, the operating system group decided to remedy the client problem by returning to the proven performance of C++ and the essentials of COM. The Windows Runtime would become the universal platform for not only the ultimate XAML implementation but also the entire Windows API.
At this point, any optimistic C++ programmer would be forgiven for thinking that the dark ages have passed and good times are ahead. Unfortunately, while the operating system group has embraced C++, the developer division remains largely unchanged. The CLR was retrofitted with support for the Windows Runtime. This is beyond ironic since .NET was specifically designed as a departure from COM with an incompatible vtable model. Performance isn’t great despite the fact that the Windows Runtime does make a number of concessions for the CLR, but at least most of the heavy lifting is now done by the operating system so C# code gets a pass.
While the operating system group has embraced C++, the developer division continues to champion C# as the tool of choice and the Visual C++ team continues to focus on standards compliance and more recently cross-platform development. Little has been done to support the Windows Runtime, certainly nothing that has captured the hearts and minds of C++ developers. C++/CLI was dusted off – a language extension designed for a garbage-collected runtime – and now offers an unnecessarily complex way to work with the Windows Runtime that makes no sense for COM. C++ is a language for library developers. The library developer’s job may not be a simple one, but you certainly have the tools at your disposal to do some amazing things. So when you hit some feature that isn’t directly supported by the language, then you write a library – you don’t go and invent a new language or write a set of language extensions. Prior to C++11 you could be forgiven for thinking in that way, but not now.
Microsoft desperately needs an infusion of modern C++ for Windows. The Universal Windows Platform built on the Windows Runtime is the ideal environment for C++ to thrive. What is missing is the determination to make it happen. Modern C++ for the Windows Runtime is the jumpstart that the Windows platform needs but it cannot happen without the support of both the operating system group and the developer division.
Jim Radigan has done some incredible work bringing code written for Android and iOS apps to Windows. Now we need to bring modern C++ to Windows as well. The C++ community is stronger than ever and forging ahead with incredible innovations to the C++ language and standard libraries. Will Windows be part of this new C++ renaissance or will this be another dark age for C++ programmers on the Windows platform?