What are the pros and cons of writing C#/XAML vs. C++/XAML WinRT applications in Windows8?
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!
Answer
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++.