¿Cuáles son los pros y los contras de escribir aplicaciones WinRT C#/XAML vs. C++/XAML en Windows8? [cerrado]


Me gustaría ir por la ruta de portar un componente WPF/Silverlight a Windows 8. Para un poco de contexto, el componente es un gráfico WPF en tiempo real, que utiliza una mezcla de WPF/XAML y representación de mapas de bits para lograr un alto rendimiento.

Me gustaría que el componente sea compatible con Metro, por ejemplo, se utiliza en el modo metro, así como el modo de escritorio. He leído mucho sobre la creación de C++/WinRT aplicaciones en Windows 8, así como C#/XAML aplicaciones, pero ¿cuáles son los las diferencias entre los dos marcos?

¿Hay limitaciones si elige C#/XAML sobre C++/XAML? También considere la portación de C # / Xaml en.NET4. 0 a Windows8 sería mucho más fácil si pudiera atenerme a C#/XAML, sin embargo, ¿podré crear un componente de Metro con todas las funciones utilizando este método?

Sus comentarios/sugerencias apreciados.

Editar:

Si estás votando para cerrar este hilo, por favor escribe un comentario por qué. Es una pregunta válida, tiene +6 votos, cuatro respuestas y un favorito. ¡Parece razonable guardármelo!

Author: CCovey, 2012-04-05

4 answers

Veo la diferencia como una elección de diseño, que una preferencia personal de lenguaje. La preferencia estaría más relacionada con VB vs C#. Y generalmente son las mismas diferencias que obtienes en cualquier aplicación donde eliges C++ o. NET.

C++ le dará tiempos de inicio más rápidos. IIRC,. NET 4.5 tiene capacidades de activación automática (no estoy seguro de cómo se relaciona con las aplicaciones de metro), por lo que esto puede ayudar a mitigar los tiempos de inicio lentos típicos de las aplicaciones de.NET.

C++ le dará un menor uso general de memoria ya que no utiliza un recolector de basura. Esto se vuelve cada vez más importante en dispositivos con recursos limitados, como las tabletas. IIRC,. NET 4.5 tiene más mitigaciones en pausas GC (que pueden causar que la interfaz de usuario se studder), todavía son una realidad con código administrado.

Dado que. NET y C++ usan el mismo framework WinRT, probablemente no habrá demasiada diferencia en interactuar con la plataforma XAML/WinRT (técnicamente interactuar más rápido con objetos WinRT a través de C++, pero el éxito es realmente pequeño), pero por supuesto su código de usuario generalmente será más rápido con C++ que .NET.

C++ es generalmente más difícil de realizar ingeniería inversa, incluso en comparación con el código.NET ofuscado. Aunque los ladrones astutos pueden robar su IP de todos modos.

Desde que.NET fue creado primero para la comodidad del desarrollador y la productividad del desarrollador, tendrá más opciones de conveniencia en la arquitectura de sus aplicaciones (por ejemplo, herramientas basadas en reflexión como DI/IoC).

Iteración el código de aplicación puede ser más fácil a través de. NET ya que.NET compila más rápido que C++, pero los proyectos C++ creados correctamente pueden mitigarse sustancialmente.

Los proyectos Pure.NET pueden soportar "Cualquier CPU", lo que significa que su aplicación puede ejecutarse en todas las plataformas WinRT compatibles. Proyectos en C++ simplemente tendrá que recompilar para soportar ARM, x86/64. Si su aplicación. NET depende de un componente C++ personalizado, tendrá que compilar para cada arquitectura.

Porque WinRT fue creado a partir del para soportar muchos lenguajes, mi sugerencia a los desarrolladores que no se sienten cómodos con C++ es seguir con. NET pero explorar áreas que se benefician de C++. Microsoft ha hecho un gran trabajo con las proyecciones / CX y la mayoría de los desarrolladores de C# deberían ser capaces de encontrar su camino. Mi sugerencia a los desarrolladores de C++ es seguir con C++ y obtener todos los beneficios de C++.

 22
Author: Jeremiah Morrill,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-04-05 20:32:18

Desde una perspectiva XAML se convierte en una elección de idioma. La pila de interfaz de usuario de XAML es la misma independientemente del idioma de código que elija aquí. Dependiendo de su objetivo de la aplicación, podría tener más sentido usar C++ si necesita los beneficios de lo que ese lenguaje le proporciona.

También tenemos la capacidad de mezclar DirectX y XAML ahora en Win8 y eso generalmente significa C++ however sin embargo, con proyectos como SharpDX que todavía no es totalmente válido (sí, me doy cuenta de que va a pagar un golpe de rendimiento en DirectX para envolver en código administrado...Solo estoy señalando que se puede hacer).

Su pregunta parece ser acerca de la creación de un componente reutilizable que se puede utilizar a través del escritorio y Metro. Esto puede ser un poco desafiante dependiendo de cómo lo diseñe debido a cómo se requirieron algunos cambios en cómo los recursos (es decir, genéricos.xaml) se cargan desde una ubicación de archivo frente a un recurso incrustado.

 3
Author: Tim Heuer,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-04-05 16:27:46

La única ventaja que se me ocurre al usar C++/XAML es que la velocidad es importante para tu proyecto. La ventaja de C# / XAML es que es mucho más fácil codificar, especialmente si tu proyecto ya está en C#.

Por ahora no hay manera de hacer una aplicación que se dirija tanto al Metro como al escritorio en Windows 8.

Espero que esto ayude.

 2
Author: Kobe,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-04-05 16:29:22

Bueno, otros pueden saber más, pero basado en La respuesta de Microsoft a una pregunta que planteé en torno a la hora del anuncio de WinRT :

WinRT es un protocolo y un conjunto de API nativas, lo que permite que cada lenguaje permanezca fiel a su entorno de ejecución existente: Chakra para JavaScript, CLR para C# y el código nativo CRT/raw para C++.

Que sugiere compensaciones de rendimiento similares a lo que experimentamos actualmente utilizando el CLR vs. código nativo para acceder a lo es esencialmente una API de código nativo (WinRT). Pero espero ver algunas investigaciones empíricas sobre esto para ver cuán diferente es WinRT.

 2
Author: ZeroBugBounce,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-04-05 16:36:05