Quels sont les avantages et les inconvénients de l'écriture d'applications C#/XAML vs. C++/XAML WinRT sous Windows8?

Question

Je voudrais passer à l'étape suivante du portage d'un composant WPF/Silverlight vers Windows 8. Pour un peu de contexte, le composant est un real-time WPF Chart qui utilise un mélange de rendu WPF/XAML et bitmap pour obtenir des performances élevées.

Je souhaite que le composant soit compatible Metro, par ex. utilisé en mode métro ainsi que le mode bureau. Je lis beaucoup sur la création de C++/WinRT applications dans Windows 8 ainsi que C#/XAML applications, mais quelles sont les différences entre les deux cadres?

Y at-il des limitations si vous choisissez C#/XAML sur C++/XAML? Considérez également le portage de C#/Xaml dans .NET4.0 à Windows8 serait beaucoup plus facile si je pouvais coller à C#/XAML, mais vais-je être en mesure de créer un composant Metro entièrement équipé en utilisant cette méthode?

Vos commentaires/suggestions ont été appréciés.

Edit:

Si vous votez pour fermer ce fil, s'il vous plaît poster un commentaire pourquoi. C'est une question valide, a +6 votes, quatre réponses et un favori. Semble raisonnable de me le garder!

Answer 1

Je vois la différence comme un choix de conception, plutôt qu'une préférence personnelle de langage. La préférence serait plus liée à VB vs C#. Et généralement, ce sont les mêmes différences que vous obtenez dans n'importe quelle application où vous choisissez C++ ou .NET.

C++ vous donnera des temps de démarrage plus rapides. IIRC, .NET 4.5 a des capacités d'auto-NGENing (je ne sais pas comment cela se rapporte aux applications Metro), donc cela peut aider à atténuer les temps de démarrage lent typique des applications .NET. C++ vous donnera moins d'utilisation de la mémoire générale car il n'utilise pas un garbage collector. Cela devient de plus en plus important sur les dispositifs à ressources limitées tels que les tablettes. IIRC, .NET 4.5 a plus d'atténuations dans les pauses GC (ce qui peut provoquer l'interface utilisateur à studder), ils sont toujours une réalité avec le code managé. Comme .NET et C++ utilisent le même framework WinRT, il n'y aura probablement pas trop de différence dans l'interaction avec la plateforme XAML/WinRT (interaction technique plus rapide avec les objets WinRT via C++ mais le hit est vraiment faible), mais bien sûr, votre code utilisateur sera généralement plus rapide avec C++ qu'avec .NET.

C++ est généralement plus difficile à désosser, même par rapport au code .NET obfusqué. Bien que les voleurs sournois peuvent voler votre IP indépendamment. Comme .NET a été créé en premier pour la commodité de la productivité des développeurs et des développeurs, vous aurez plus d'options pratiques pour l'architecture de vos applications (par exemple, des outils basés sur la réflexion tels que DI/IoC).

L'écriture de code d'application peut être plus facile via .NET car .NET compile plus rapidement que C++, mais les projets C++ correctement créés peuvent être considérablement réduits.

Les projets .NET purs peuvent prendre en charge «Any CPU», ce qui signifie que votre application peut s'exécuter sur toutes les plates-formes WinRT prises en charge. Projets C++ que vous devrez simplement recompiler pour prendre en charge ARM, x86/64. Si votre application .NET dépend d'un composant C++ personnalisé, vous devrez compiler pour chaque architecture. Étant donné que WinRT a été créé à partir de zéro pour prendre en charge de nombreux langages, ma suggestion aux développeurs qui ne sont pas à l'aise avec C++ est de s'en tenir à .NET mais d'explorer les zones qui bénéficient de C++. Microsoft a fait un excellent travail avec les projections/CX et la plupart des développeurs C# devraient être en mesure de trouver leur chemin. Ma suggestion aux devs C++ est de coller avec C++ et obtenir tous les avantages de C++.

Answer 2

D'un point de vue XAML il devient un choix de langue. La pile d'interface utilisateur XAML est la même quel que soit le langage de code que vous choisissez ici. Selon votre objectif de l'application, il peut être plus judicieux d'utiliser C++ si vous avez besoin des avantages de ce langage. Nous avons également la possibilité de mélanger DirectX et XAML maintenant dans Win8 et cela signifie généralement C++ - mais avec des projets comme SharpDX qui ne sont pas encore totalement valide (oui, je sais que vous allez payer un hit de performance dans DirectX pour envelopper dans le code managé ... Je ne fais que souligner que cela peut être fait).

Votre question semble porter sur la création d'un composant réutilisable qui peut être utilisé sur le bureau et Metro. Cela peut être un peu un peu difficile en fonction de la façon dont vous l'avez architecturé en raison de la façon dont certains changements ont été nécessaires à la façon dont les ressources (ie generic.xaml) sont chargées à partir d'un emplacement de fichier par rapport à une ressource incorporée.

Answer 3

Le seul avantage que je peux imaginer pour utiliser C++/XAML est si la vitesse est importante pour votre projet. L'avantage de C#/XAML est qu'il est beaucoup plus facile de coder, surtout si votre projet est déjà en C#.

Maintenant il n'y a pas moyen de faire une application qui cible à la fois le métro et le bureau dans Windows 8.

Hope this helps.

Answer 4

autres bien peuvent en savoir plus, mais basé sur Microsoft's answer to a question I posed back around WinRT announcement time:

WinRT est un protocole et un ensemble d'API natives, permettant à chaque langue de rester fidèle à son environnement d'exécution existant - Chakra pour JavaScript, CLR pour C# et le code natif CRT/raw pour C++.

Ce suggère compromis de performance similaires à ce que nous vivons actuellement en utilisant le CLR vs code natif pour accéder à ce qui est essentiellement une API de code natif (WinRT). Mais j'ai hâte de voir des recherches empiriques pour voir à quel point WinRT est différent.