4 ms·
Coding in C++/WinRT (similaly, C++/CX) is in my experience a major mistake when targeting WinRT/UWP using C++. The primary use case for WinRT/UWP is making app
by optimiz3 6y ago
Coding in C++/WinRT (similaly, C++/CX) is in my experience a major mistake when targeting WinRT/UWP using C++. The primary use case for WinRT/UWP is making apps for the Microsoft Store, where most of the time you're going to be sharing code also targeting Google Play and the Apple Store given those markets are vastly larger (and have viable ad-platforms; Microsoft is shutting theirs down on June 1st).
The C++/WinRT and C++/CX language projections are incompatible with compilers that target Android and IOS due to WinRT reference specific syntax and keywords such as the '^' reference indicator.
As an alternative, it is possible to access all of the same WinRT/UWP platform functionality in pure C++ without the C++/WinRT syntactic sugar extensions, allowing you to cleanly abstract the WinRT/UWP platform APIs relative to Android and IOS. This is not well documented but by far a superior option for folks familiar with COM and Windows internals.
Furthermore, avoiding things like '^' reference operator syntax gives you tighter control over object lifetime as C++/WinRT and C++/CX hide to some degree the mechanics of COM object lifetime and gives a pseudo-environment much more like C# on .Net.
Microsoft does provide the WRL pure C++ template library, which is in many ways a spiritual successor to the ATL COM template library. WRL is in my experience the best way to interact with COM objects surrounding WinRT and UWP.
(Source: developer of several top 10 apps (at times) on Microsoft Store).
Glossary of Microsoft terms:
WinRT/UWP (WinRT (Windows Runtime) the old name used in Windows 8/8.1 for what later was renamed to UWP (Universal Windows Platform) in Windows 10). WinRT/UWP was originally intended to be an object-oriented replacement API for Win32 but hasn't lived up to its charter due to only being useful for Microsoft Store apps and being significantly less capable than Win32.
COM - Component Object Model; an object-oriented API style used by some Win32 APIs, this style was used near-exclusively as the basis for the WinRT APIs. COM can be unweildy to deal with so there are several C++ template libraries like WRL and ATL to make it easier.
C++/WinRT (and C++/CX) are Microsoft specific C++ extensions that require MSVC and hide the complexity of dealing with COM relative to WinRT/UWP APIs.
- hyperrail 6y agoC++/WinRT and C++/CX are not the same; they are different enough that Microsoft Docs has a whole page explaining how to move from C++/CX to C++/WinRT: https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/move-to-winrt-from-cx https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-a... In particular only the older C++/CX has ^ pointers or other Microsoft-specific C++ language extensions. C++/WinRT is standard C++. Writing your code using WRL (Windows Runtime C++ template Library) is good if you want to learn enough about how the Windows Runtime extensions to COM work in order to debug effectively. However, its close relationship to the underlying COM and Windows Runtime APIs also makes it far too verbose to quickly write good API-consuming and -producing code, in my opinion.
- optimiz3 6y agoUpdated my post - I had forgotten C++/WinRT discarded the ^ syntax as we skipped C++/WinRT for our development as it suffers from many of the same problems of C++/CX.
- projektfu 6y agoI think C++/WinRT is more of a "modern C++" projection than C++/CX, and they aren't an also-known-as, although they meet similar goals. For example, with the ^ reference: https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/move-to-winrt-from-cx#parameter-passing https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-a...
- pjmlp 6y agoJust like Qt depends on moc. GCC and clang are also full of language extensions. In fact if it wasn't for the work of Google, to this day Linux would only be compilable with GCC C. I remember C devs on Apple platforms being happy for their lambdas extensions when they were introduced. So I never understand why everyone else is allowed to create language extensions, but when Microsoft does it is bad.