Quels sont les avantages et les inconvénients de l'écriture d'applications C # / Xaml par rapport aux applications C ++ / Xaml WinRT sous Windows8?

Question

J'aimerais aller en bas de la route de portage d'un WPF/Silverlight composant de Windows 8. Pour un peu de contexte, le composant est un temps réel WPF Graphique, qui utilise un mélange de WPF/Xaml et bitmap rendu à atteindre la haute performance.

J'aimerais le composant de Métro compatible, par exemple, utilisé dans le métro de mode ainsi que le mode de bureau. J'ai lu beaucoup de choses 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?

Il y a des restrictions si vous choisissez C#/Xaml sur C++/Xaml? Également envisager le portage en C#/Xaml .NET4.0 à Windows8 serait beaucoup plus facile si je pouvais coller à C#/Xaml, cependant je serai en mesure de créer un complet Métro composant à l'aide de cette méthode?

Vos commentaires/suggestions apprécié.

Edit:

Si vous êtes à droit de vote de fermer ce fil, s'il vous plaît poster un commentaire pourquoi. Ses une question valable, a +de 6 voix, quatre réponses et un favori. Semble raisonnable de le garder pour moi!

Answer 1

Je vois la différence comme un choix de conception, qu'une préférence personnelle de la langue. La préférence serait plus liée à VB vs C#. Et généralement, c'est les mêmes différences que vous pouvez obtenir dans n'importe quelle application où vous pouvez choisir C++ ou .NET.

C++ vous donnera plus rapide temps de démarrage. IIRC, .NET 4.5 a l'auto NGENing capacités (pas sûr de la façon dont elle est liée aux applications metro), ce qui peut aider à atténuer typique de démarrage lent de temps de .NET applications.

C++ vous donnera à réduire l'utilisation de la mémoire car il n'utilise pas de garbage collector. Cela devient de plus en plus importante sur les ressources limitées des appareils tels que les tablettes. IIRC, .NET 4.5 a plus de mesures d'atténuation en GC des pauses (qui peut causer de l'INTERFACE utilisateur studder), ils sont encore une réalité avec le code managé.

Depuis .NET et C++ utilise le même WinRT cadre, il ne sera probablement pas trop de différence dans l'interaction avec le XAML/WinRT plate-forme (techniquement plus rapide de l'interaction avec les objets WinRT via C++, mais le coup est vraiment petit), mais bien sûr, votre code d'utilisateur sera généralement plus rapide avec le C++ que .NET.

C++ est généralement plus difficile à déjouer, même en comparaison avec d'obfuscation .NET code. Si sly voleurs peuvent voler votre IP, peu importe.

Depuis .NET a été créée d'abord pour la commodité du développeur et la productivité des développeurs, vous aurez plus de commodité options dans l'architecture de vos applications (par exemple, la réflexion basée sur des outils tels que le DI/Cio).

L'itération du code de l'application peut être plus facile par l'intermédiaire .NET comme .NET compile plus rapide que le C++, mais correctement créé les projets C++ cet effet peut être atténué sensiblement.

Pure .NET les projets peuvent soutenir "any CPU", ce qui signifie que votre application peut s'exécuter sur toutes les éditions WinRT plates-formes. Les projets C++, vous aurez simplement à recompiler à l'appui de BRAS, x86/64. Si vous .NET application dépend d'un personnalisé composant C++, vous devrez le compiler pour chaque architecture.

Parce que WinRT a été créé à partir du sol en place pour prendre en charge plusieurs langues, ma suggestion pour les devs qui ne coûtent pas à l'aise avec le C++ est de coller avec .NET, mais d'explorer des domaines qui bénéficient de C++. Microsoft a fait un bon travail avec l' /CX projections et de plus C# devs devraient être en mesure de trouver leur chemin. Ma suggestion pour C++ devs est de coller avec C++ et obtenir tous les avantages du C++.

Answer 2

À partir d'un code XAML perspective, il devient un choix de langue. Le code XAML de l'INTERFACE utilisateur de la pile est la même quel que soit le code de la langue que vous choisissez ici. En fonction de votre objectif de l'application, il peut être plus judicieux d'utiliser le C++ si vous avez besoin des avantages de ce que la langue fournit vous.

Nous avons également la possibilité de mixer de DirectX et XAML maintenant dans Win8 et cela signifie généralement C++ -- cependant, avec des projets comme SharpDX qui n'est pas encore totalement valide (oui je me rends compte que vous allez payer une performances en DirectX pour l'emballage dans du code managé...je suis juste en indiquant que l'on peut faire).

Votre question semble être sur la création d'une ré-utilisable composant qui peut être utilisé dans le bureau et le Métro. Cela peut être un défi un peu selon la façon dont vous l'architecte raison de la façon dont des changements étaient nécessaires à la façon dont les ressources (c'est à dire, générique.xaml) sont chargés à partir d'un emplacement de fichier par rapport à une ressource incorporée.

Answer 3

Le seul avantage que je puisse penser à utiliser C ++ / XAML est que la rapidité 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 #.

À l'heure actuelle, il n'existe aucun moyen de créer une application qui cible à la fois le métro et le bureau dans Windows 8.

J'espère que cela t'aides.

Answer 4

Bien d'autres peuvent en savoir plus, mais en fonction de la réponse de Microsoft à une question que j'ai posée en arrière autour de WinRT annonce temps:

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

Que suggère des performances similaires compromis à ce que nous avons actuellement de l'expérience à l'aide de la CLR vs code natif pour accéder à ce qui est essentiellement un code natif (API WinRT). Mais j'ai hâte de voir certaines enquêtes empiriques dans ce pour voir comment les différents WinRT est.