Microsoft (chiefly, Herb Sutter) recommends when using WinRT with C++/CX to keep WinRT at the boundaries of the application and keep the core of the application written in standard ISO C++.
I’ve been writing an application which I would like to leave portable, so my core functionality was written in standard C++, and I am now attempting to write a Metro-style front end for it using C++/CX. I’ve had a bit of a problem with this approach, however. For example, if I want to push a vector of user-defined C++ types to a XAML ListView control, I have to wrap my user-defined type in a WinRT ref/value type for it to be stored in a Vector^. With this approach, I’m inevitably left with wrapping a large portion of my C++ classes with WinRT classes.
This is the first time I’ve tried to write a portable native application in C++. Is it really practical to keep WinRT along the boundaries like this? How else could this type of portable core with a platform-specific boundary be handled?
16
IMHO (old programmer; work at Microsoft but this is a personal opinion): before I can answer this question, you have to anwser this other question:
Where is the code moving to? If you’re sticking with a single platform (in this case, WinRT), then be close to the platform — and that means using the existing abstractions. Per your example, your code would then use Vector^ in order to match the WinRT needs.
OTOH, if you’re moving somewhere else (VMS rocks!), then standards based makes sense.
Given that the three biggest portable, tablet-like platforms in the marketplace all use different languages for common programming tasks, moving the code might not be a valuable option.
2
You don’t have to use C++/CX, instead you can use the WRL (Windows Runtime Library) which is like the old ATL templates, not the ‘pretend’ C++ that is C++/CX. Its the “low level” approach from MS to consuming WinRT objects and is completely standard C++ like Grandad used to write!
It might not be as “nice” as C++/CX but that’s a matter of opinion – my personal opinion is that C++/CX is the 3rd attempt at an extended C++, and is a 3rd failure. Ignore it and hope it goes the same way as the other 2 incarnations.