The State of C++ on Windows

As the 2019 State of the Union Address appears to be postponed, I thought I would offer you the State of C++ on Windows instead!

C++ continues to be an important programing language in general and the only systems programming language of any consequence on the Windows platform. The Visual Studio 2019 release has some incredible improvements that I hope to share more about in the coming weeks, but right now I want to give you an update on the state of C++/WinRT.

C++/WinRT continues to gain adoption as developers eschew WRL and C++/CX in favor of modern and standard C++. You may have heard that the Windows UI Library was recently open sourced. Did you also notice that it is written entirely in C++/WinRT? That’s just one high-profile example, but there are many teams that have made the switch and we are strongly discouraging anyone from using WRL or C++/CX going forward.

Even as C++/WinRT is used to implement large parts of Xaml, adoption of C++/WinRT for building Xaml apps is slow. It helps to recognize that there are three categories or scenarios where C++/WinRT comes into play most frequently.

1. Using or calling Windows APIs (otherwise known as consuming WinRT types)

2. Authoring Windows APIs (otherwise known as producing WinRT types)

3. Authoring Xaml apps and controls

The first one involves making API calls using C++/WinRT to do things like communicate using Bluetooth, stream and present video, integrate with the Windows shell, and so on. The second involves authoring APIs that provide such capabilities, the graphics APIs, the storage and file system APIs, the networking APIs, and so on. The third involves writing apps and controls built on the Xaml framework. While Xaml is just one of those APIs, it is the dominant UI framework on Windows today and it has an outsized influence over WinRT, so it deserves its own category.

C++/WinRT fully and uncompromisingly supports the first category. Authoring brand new WinRT APIs is a little more involved because a developer must use IDL to define the shape of the API before the developer can implement the API. This is however not substantially more complicated than using C++/CX and, given the many benefits of using C++/WinRT, developers are generally very happy with the trade. It is the third category where things fall apart. Xaml was designed for .NET and assumes and effectively requires reflection to function as intended. While you can write Xaml apps with C++/WinRT, it is pretty cumbersome. This is where the C++ reflection proposal would be very valuable.

Still, I am hopeful that we can turn that around. It pains me that Windows does not have a good UI story for C++ developers. C++ reflection may well help to solve that problem in the long run, but we cannot wait for that to arrive, so we are also exploring some other options that may prove useful in the near future. Some of those include alternative approaches to Xaml that does not require reflection, as well as discussions with DevDiv to get Visual Studio to do a better job of supporting a C++/WinRT developer experience.

Stay tuned for more on C++/WinRT and xlang. A lot has been going on – I’ve just been heads down getting it down, but I plan to start writing again and sharing some of the work that we’ve been doing.