Quali sono i pro e i contro della scrittura di applicazioni C#/XAML rispetto a C++/XAML WinRT in Windows8?

Question

Mi piacerebbe seguire il percorso di porting di un componente WPF/Silverlight su Windows 8. Per un po 'di contesto, il componente è uno real-time WPF Chart, che utilizza una combinazione di WPF/XAML e rendering bitmap per ottenere prestazioni elevate.

Vorrei che il componente fosse compatibile con Metro, ad es. utilizzato in modalità metropolitana e desktop. Ho letto molto sulla creazione di applicazioni C++/WinRT in Windows 8 e sulle applicazioni C#/XAML, ma quali sono le differenze tra i due framework?

Esistono limitazioni se si sceglie C#/XAML su C++/XAML? Considerare anche il porting da C#/Xaml in .NET4.0 a Windows8 sarebbe molto più semplice se potessi limitarmi a C#/XAML, tuttavia sarò in grado di creare un componente Metro completo con questo metodo?

I vostri commenti/suggerimenti sono apprezzati.

Edit:

Se stai votando per chiudere questa discussione, si prega di inviare un commento per questo. È una domanda valida, ha +6 voti, quattro risposte e una preferita. Sembra ragionevole tenerlo a me!

Answer 1

Vedo la differenza come una scelta progettuale, piuttosto che una preferenza personale del linguaggio. La preferenza sarebbe più correlata a VB vs C#. E generalmente sono le stesse differenze che si ottengono in qualsiasi applicazione in cui si sceglie C++ o .NET.

C++ ti darà tempi di avvio più rapidi. IIRC, .NET 4.5 ha capacità di NGENing automatiche (non sono sicuro in che modo si riferiva alle app della metropolitana), quindi questo potrebbe aiutare a mitigare i tempi di avvio lenti tipici delle applicazioni .NET.

C++ consente di ridurre l'utilizzo della memoria generale in quanto non utilizza un garbage collector. Questo diventa sempre più importante su dispositivi con risorse limitate come i tablet. IIRC, .NET 4.5 ha più attenuazioni nelle pause GC (che possono causare l'interfaccia utente allo studder), sono ancora una realtà con il codice gestito.

Poiché .NET e C++ utilizzano lo stesso framework WinRT, probabilmente non ci saranno troppe differenze nell'interazione con la piattaforma XAML/WinRT (l'interazione tecnicamente più rapida con oggetti WinRT tramite C++ ma l'hit è veramente piccolo), ma ovviamente il tuo codice utente sarà generalmente più veloce con C++ che .NET.

C++ è generalmente più difficile da decodificare, anche se confrontato con codice .NET offuscato. Anche se i furbi ladri possono rubare il tuo IP a prescindere.

Poiché .NET è stato creato innanzitutto per la produttività dello sviluppatore e dello sviluppatore, avrete più opzioni di convenienza nell'architettura delle vostre applicazioni (ad esempio, strumenti basati sulla riflessione come DI/IoC).

Iterare il codice dell'applicazione può essere più semplice tramite .NET poiché .NET è più veloce di C++, ma i progetti C++ correttamente creati possono essere mitigati in modo sostanziale.

I progetti .NET puri possono supportare "Qualsiasi CPU", il che significa che l'applicazione può essere eseguita su tutte le piattaforme WinRT supportate. I progetti C++ dovranno semplicemente essere ricompilati per supportare ARM, x86/64. Se l'applicazione .NET dipende da un componente C++ personalizzato, sarà necessario compilare per ogni architettura.

Poiché WinRT è stato creato da zero per supportare molte lingue, il mio suggerimento per gli sviluppatori che non sono a proprio agio con C++ è quello di continuare con .NET ma esplorare aree che traggono vantaggio dal C++. Microsoft ha fatto un ottimo lavoro con le proiezioni/CX e molti sviluppatori di C# dovrebbero essere in grado di orientarsi. Il mio suggerimento per gli sviluppatori C++ è quello di rimanere con C++ e ottenere tutti i vantaggi del C++.

Answer 2

Da una prospettiva XAML diventa una scelta linguistica. Lo stack UI XAML è lo stesso indipendentemente dalla lingua del codice scelta qui. A seconda del tuo obiettivo dell'app, potrebbe essere più sensato usare C++ se hai bisogno dei benefici di ciò che ti fornisce questa lingua.

Abbiamo anche la possibilità di mixare DirectX e XAML ora in Win8 e che in genere significa C++, tuttavia con progetti come SharpDX che non sono ancora completamente validi (sì, mi rendo conto che pagheresti un calo di prestazioni in DirectX per avvolgimento nel codice gestito ... sto solo precisando che può essere fatto).

La tua domanda sembra essere sulla creazione di un componente riutilizzabile che può essere utilizzato su desktop e Metro. Questo potrebbe essere un po 'impegnativo un po' a seconda di come lo si è architettato a causa di come sono state richieste alcune modifiche al modo in cui le risorse (ad esempio, generic.xaml) vengono caricate da un percorso file rispetto a una risorsa incorporata.

Answer 3

L'unico vantaggio che posso pensare di utilizzare C++/XAML è se la velocità è importante per il progetto. Il vantaggio di C#/XAML è molto più facile da codificare, specialmente se il progetto è già in C#.

Ormai non c'è modo di presentare una domanda che gli obiettivi sia la metropolitana e il desktop di Windows 8.

Spero che questo aiuti.

Answer 4

bene gli altri possono sapere di più, ma sulla base di Microsoft's answer to a question I posed back around WinRT announcement time:

WinRT è un protocollo e un set di API native, consentendo ogni lingua di rimanere fedele al suo ambiente di esecuzione esistente - Chakra per JavaScript, CLR per C# e il CRT/codice nativo grezzo per C++.

Che suggerisce simili prestazioni compromessi a quello che attualmente sperimentiamo utilizzando il codice nativo CLR vs per accedere a ciò che è essenzialmente un codice API native (WinRT). Ma non vedo l'ora di vedere alcune indagini empiriche su questo per vedere quanto sia diverso WinRT.