What are the pros and cons of writing C#/XAML vs. C++/XAML WinRT applications in Windows8?

Question

I'd like to go down the route of porting a WPF/Silverlight component to Windows 8. For a bit of context, the component is a real-time WPF Chart, which uses a mixture of WPF/XAML and bitmap rendering to achieve high performance.

I'd like the component to be Metro compatible, e.g. used in metro mode as well as desktop mode. I read a lot about creating C++/WinRT applications in Windows 8 as well as C#/XAML applications, but what are the differences between the two frameworks?

Are there limitations if you choose C#/XAML over C++/XAML? Also consider the porting from C#/Xaml in .NET4.0 to Windows8 would be far easier if I could stick to C#/XAML, however will I be able to create a fully featured Metro component using this method?

Your comments/suggestions appreciated.

Edit:

If you're voting to close this thread, please post a comment why. Its a valid question, has +6 votes, four answers and one favourite. Seems reasonable to keep it to me!

Solution 1

I see the difference as a design choice, than a personal preference of language. Preference would be more related to VB vs C#. And generally it's the same differences you get in any application where you choose C++ or .NET.

C++ will give you faster startup times. IIRC, .NET 4.5 has auto NGENing abilities (not sure how it related to metro apps), so this may help mitigate typical slow startup times of .NET applications.

C++ will give you lower general memory usage as it does not use a garbage collector. This becomes increasingly more important on resource constrained devices such as tablets. IIRC, .NET 4.5 has more mitigations into GC pauses (which can cause the UI to studder), they are still a reality with managed code.

Since .NET and C++ use the same WinRT framework, there probably won't be too much difference in interacting with the XAML/WinRT platform (technically faster interacting with WinRT objects via C++ but the hit is really small), but of course your user code will generally be faster with C++ than .NET.

C++ is generally more difficult to reverse engineer, even when compared with obfuscated .NET code. Though sly thieves can steal your IP regardless.

Since .NET was created first for the convenience of the developer and developer productivity, you will have more convenience options in architecting your applications (eg, reflection based tools such as DI/IoC).

Iterating application code may be easier via .NET as .NET compiles quicker than C++, but correctly created C++ projects this can be mitigated substantially.

Pure .NET projects can support "Any CPU", which means your application can run on all supported WinRT platforms. C++ projects you will simply have to recompile to support ARM, x86/64. If you .NET application depends on a custom C++ component, you will have to compile for each architecture.

Because WinRT was created from the ground up to support many languages, my suggestion to devs that arent comfortable with C++ is to stick with .NET but explore areas that benefit from C++. Microsoft has done a great job with the /CX projections and most C# devs should be able to find their way around. My suggestion to C++ devs is to stick with C++ and get all the benefits of C++.

Solution 2

From a XAML perspective it becomes a language choice. The XAML UI stack is the same regardless of which code language you choose here. Depending on your goal of the app it might make more sense to use C++ if you need the benefits of what that language provides you.

We also have the ability to mix DirectX and XAML now in Win8 and that usually means C++ -- however with projects like SharpDX that still isn't totally valid (yes I realize you will be paying a performance hit in DirectX for wrapping in managed code...I'm just pointing out it can be done).

Your question seems to be about creating a re-usable component that can be used across the desktop and Metro. This may be somewhat challenging a bit depending on how you architect it because of how some changes were required to how resources (i.e., generic.xaml) are loaded from a file location versus an embedded resource.

Solution 3

The only advantage I can think of to use C++/XAML is if speed is important to your project. The advantage of C#/XAML is that is much more easier to code, especially if your project its in C# already.

By now there is no way to make an application that targets both the Metro and the desktop in Windows 8.

Hope this helps.

Solution 4

Well others may know more, but based on Microsoft's answer to a question I posed back around WinRT announcement time:

WinRT is a protocol and a set of Native APIs, allowing each language to remain true to its existing execution environment - Chakra for JavaScript, CLR for C# and the CRT/raw native code for C++.

That suggests similar performance trade-offs to what we currently experience using the CLR vs. native code to access what is essentially a native code API (WinRT). But I look forward to seeing some empirical investigations into this to see just how different WinRT is.

View more solutions

Comments

[Adrian]

If speed is important, use C++/XAML, if not use C#/XAML it will be more easier for you as you said

[Dr. Andrew Burnett-Thompson]

But will it really be faster in C++? The old argument C# vs C++ for speed. You can mitigate a lot of C#'s flaws by better coding. What I need to know is, are the feature sets for C# vs. C++ different. E.g. can I create a fully featured component in C#/Xaml to target both metro and desktop modes? Thanks!

[Adrian]

In C++ is always faster, but you cannot create a project that runs in both Metro and desktop too. It has to be one or the other

[Dr. Andrew Burnett-Thompson]

Crazy. So can you dual deploy? Like how you write code for Silverlight and WPF and "share" the code as link? BTW if you write up what you know as answer I'd be pleased to vote up :)

[IInspectable]

@Kobe: Wrong, wrong, and wrong. C++ vs. C# for a component writer has a different answer. Going with C++ is favorable, as it doesn't drag in additional dependencies. Clients may not use your component, because their C++ code doesn't want to have the CLR loaded. Next up: Performance. C# beats C++, by a significant margin with respect to heap management. If your app creates many short-lived, small objects, you'll see C# code running an order of magnitude faster. Besides, a WinRT component can be used in a Windows Store App as well as in a Desktop App.

[Dr. Andrew Burnett-Thompson]

I actually read that article on C#/Xaml and SharDX: advertboy.wordpress.com/2012/04/04/… Very good indeed. I do want speed but also ease of port. This is an existing component in C#/WPF and a shared codebase would make me v. happy :-)

[Dr. Andrew Burnett-Thompson]

I'm guessing that WinRT C++ components can be consumed in C++/WinRT OR .NET whereas .NET components can only be consumed in .NET. Does that sound right?

[Adrian]

I think this will make you understand better :) en.wikipedia.org/wiki/Windows_Runtime

[K Mehta]

+1 You can see the Microsoft flavor in the response when @TimHeuer says "We also have..." :)

[Dr. Andrew Burnett-Thompson]

Wow, thanks for the comparison / rundown. Can I ask a question? If I author a C#/Xaml usercontrol, can it be used in C++/WinRT apps or just C# apps?

[Jeremiah Morrill]

You can use a C# WinRT component from a C++ application. Though devs should be aware they are bringing the whole CLR dependency with it...So some pure C++ applications may shy off from using it.

[Dr. Andrew Burnett-Thompson]

Got it. Well for a Win8 debut a straight port of an existing component to C# sounds like the best option. However for more specialist apps it may well be worth developing in C++

[IInspectable]

There are many advantages to using C++ (either plain, or C++/CX), and performance is probably the least important one. With .NET Native out, startup times have reached comparable figures. What's more important, though (to me, anyway): Deterministic garbage collection. In C++ you can see, where objects are disposed, and where destructors run. In .NET you often have to guess, and if an object wraps a native, shared resource, things can easily break. Maybe even more importantly: C++ components can be used in any application, without dragging in a CLR dependency.