|Written by Mike James|
|Wednesday, 26 October 2016|
Microsoft has had a problem about how to make Universal Windows Apps easy to create from C++. The initial approach was to modify the language but this has now been dropped in favour of adding a library to standard C++.
Microsoft really can't make up its mind how best to do things. Once upon a time we had bold initiatives like .NET that were viewed by many as a revolution but eventually it all turned out well. Recently however there have been far too many retreats from positions that seemed immutable. So it is with C++/CX.
When WinRT was introduced with Windows 8 some way was needed to allow C++ programmers to create what we then called Metro apps. These morphed into Windows Store apps and we now call them Universal Windows Apps (UWA) - despite the fact that they only run on Windows 10. Languages like C# could have the extra libraries added without any major changes, but C++ is a language that is more varied in the environments it runs in and it is standardized.
However this didn't stop Microsoft modifying C++ as supported in Visual Studio to create C++/CX:
As the Modern C++ for the Windows Runtime blog post puts it:
"C++/WinRT is the future of the Modern project and the first public preview coming officially from Microsoft."
In other words, forget C++/CX and start using this instead.
The GitHub Read Me explains:
"C++/WinRT is a standard C++ language projection for the Windows Runtime implemented solely in header files. It allows you to both author and consume Windows Runtime APIs using any standards-compliant C++ compiler."
What isn't made clear anywhere is why Microsoft, and more importantly us, wasted time on C++/CX. The new release is much improved:
"Significant improvements have been made to virtually all parts of the base library including the metaprogramming facilities, string and error handling. We’ve also added support for various missing features include arrays, collections, and weak references. Delegates are now more efficient and it’s possible to implement any WinRT interface within the projection. This update also includes our complete async programming model based on coroutines."
All good news, but there is still a small shock to be had in the statement of future direction:
"We’re now switching gears to focus on Xaml and component support among other things. "
The other languages using WinRT take Xaml support for-granted; not so C++.
The library is open source under an MIT licence. At the moment there seems to be very activity on the C++WinRT front. If you search on Google for "how-to" articles you mostly find C++/CX results.
What does this mean?
It could be that there aren't many C++ programmers interested in creating WinRT apps.
Overall moving to standard C++ has to be a good idea, but why did we have to take the detour?
or email your comment to: firstname.lastname@example.org
|Last Updated ( Wednesday, 26 October 2016 )|