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?

  • Something like MVVM, where Model is standard C++, V and VM are WinRT interop objects?
    – Max
    Aug 7, 2012 at 17:09
  • 5
    "but each VM effectively turns into a wrapper around my standard models." - that's pretty common for view models in any scenario.
    – MattDavey
    Aug 7, 2012 at 18:19
  • 1
    @GlenH7, I believe comments have mostly answered this for me. I had reached the same conclusion, but was hoping someone had a more clever idea in mind. In general, things are just the way they are. You can do your best to isolate portions of your code, but for the most part you will end up needing to rewrite platform-specific portions of the code (such as in the ViewModel examples above).
    – Bret Kuhns
    Sep 7, 2012 at 15:41
  • 1
    @GlenH7 Perhaps the only way to keep your application code consistent across platforms is to write your own platform abstraction layer, but those layers will end up being what I was trying to avoid in the first place. It's simply moving the problem around with a layer abstraction to isolate things. Perhaps helps, but in the end you're still doing the work.
    – Bret Kuhns
    Sep 7, 2012 at 15:43
  • 1
    We tried once to create a "silver bullet" to seamlessly glue a C library to Java on Android. Finally it could work, after spending ~×10 more time and using exotic debugging techniques (to work around the abnormal behaviour on the frontier). Definitely, it was fun.
    – Alex Cohn
    Oct 9, 2012 at 17:18

2 Answers 2


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.

  • I agree. I started the project targeting WinRT, but knowing Android/iOS would be attractive platforms to port to, which prompted this question. I've since decided to write specifically against WinRT only. If the project itself draws a crowd, I'll worry about porting (or rather, rewriting to another platform) then.
    – Bret Kuhns
    Oct 14, 2012 at 17:46
  • As @alexcohn pointed out, if the core functionality is heavy enough at the time that I decide to go cross platform, then it will be worth wrapping portable code with platform specific layers. Otherwise, I'll just rewrite the code and use test suites to verify behavior across different platforms (where appropriate).
    – Bret Kuhns
    Oct 14, 2012 at 17:49

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.