C ++ / CLI o C # para crear una GUI rápida, moderna y con capacidad de respuesta en Windows

Actualmente estoy dividido entre estos dos idiomas. Estoy casi a la mitad de la progtwigción de mi aplicación actual, que debe ser muy rápida. Calcula estructuras de vidrio aisladas de cualquier tipo en múltiples condiciones de carga.

Simplemente no sé si es la opción correcta para escribirlo en C ++ / CLI. En Internet, por ejemplo, nunca leí el nombre “C ++ / CLI”, pero todos aconsejan aprender C #.

¿Cuáles son realmente las desventajas de C ++ / CLI ? Me he enterado de mi lectura de que está condenado a ser desaprobado en los próximos años. ¿Es esto cierto? Y si hay algunos, ¿son tan malos que realmente es necesario cambiar a C #?

Lo único que habla actualmente en contra de C # es que tengo un código C al que necesito acceder y no puedo crear .Dll debido a problemas de seguridad y prevención de pirateos. (El progtwig será muy caro)

¿Qué otras oportunidades tengo para escribir una GUI rápida que se ejecute en Windows (también con Animación 3D y Multi-Core e incluso Procesamiento Graphic-Core)?

Buscando un mayor rendimiento, había portado una gran cantidad de C # / WPF UI a C ++ / CLI (que ha evolucionado a C ++ / CX en lo que respecta a WinRT ). Es importante recordar que no es C ++, sino un conjunto de extensiones administradas para que el lenguaje C ++ sea compatible con .NET. Me encanta la encoding de UI de bajo nivel y, a menudo, escribí la mayoría de los controles en WPF, derivados de DrawingVisual o UIElement , según los requisitos de entrada del usuario.

Personalmente no me gustaban las ‘extensiones’ (como usar sombreros ^) y me parecieron muy poco naturales. No vi grandes ganancias de C # (y las nuevas versiones 4.6 parecen haber realizado mejoras adicionales). Personalmente creo que C ++ / CLI pronto será cosa del pasado. Definitivamente no estoy solo con mi disgusto por C ++ / CLI, y los tipos como Kenny Kerr han tenido un gran impacto en todo el asunto. De hecho, predigo que MS adoptará su biblioteca y Sunset C ++ / CLI por completo.

Después de descargar todo el proyecto y migrar a C ++ / Direct2D puro. Subestimé enormemente el tiempo de desarrollo, pero encontré GRANDES ganancias. No es un camino fácil, ya que escribirá sus propios controles (cuadros de texto y todo). Sin embargo, ahora hay Win2D (envoltorio de Direct2D) que proporciona esos controles y parece ser una gran solución (sin embargo, no estaba disponible cuando comencé y no tengo intención de cambiar ahora).

No podría estar más feliz con mi decisión ahora, pero ciertamente tenía algunas dudas en el camino, y no necesariamente recomendaría ese esfuerzo, a menos que su corazón esté realmente en ello por mucho tiempo. De lo contrario, quédate con lo que sabes.

EDITAR: Y, por cierto, cualquiera de los que dicen que C # / WPF es tan rápido como C ++ / DirectX está en negación o delirante. Y con algunas de las mejoras del optimizador incluidas en VS2015, se sorprenderá de la huella pequeña y del rendimiento que se obtendrá. Y eliminar la dependencia de .NET es una gran pérdida de peso, mientras que resulta muy difícil para quienes pretenden realizar ingeniería inversa de su producto.

EDITAR 2: Si actualmente no sabe C # / WPF, entonces, por supuesto, evítelo , especialmente porque tiene un código C existente (por lo que he subestimado la respuesta de Dave). Y si el rendimiento es crítico, ahora es el momento perfecto para saltar a DirectX 12 (el mejor rendimiento posible de MS Tech). Buena suerte, suena como un proyecto divertido.

EDICIÓN 3: Como se indicó anteriormente (con respecto a Kenny Kerr), aquí hay un anuncio reciente que probablemente comenzará la nueva era, y la puesta del sol C ++ / CLI y C ++ / CX.

El ‘problema’ con C ++ / CLI es que C ++ es uno de los lenguajes de nivel superior más complicados (aunque algunos dirían que no es un lenguaje de alto nivel). Por lo tanto, crear una aplicación, especialmente basada en GUI, es mucho más difícil que en C # u otro lenguaje similar moderno. También es mucho más fácil cometer errores drásticos que son muy difíciles de depurar y rastrear, aunque la parte CLI de esa combinación lo hace más fácil o resuelve algunos de los problemas que podría encontrar.

Por otro lado, es en cierto modo más fácil de optimizar, si es que se necesita, y la interoperabilidad con el código C es muy fácil. Por otro lado, también es muy fácil escribir código C ++ con un rendimiento muy bajo si no sabes lo que estás haciendo. Por lo tanto, si no conoce C ++, le recomendaría que se mantenga alejado de él para un proyecto crítico, ya que sería dudoso que usted entregara un progtwig que funcione, y mucho menos uno rápido.

C # puede ser igual de rápido, pero hay varias cosas que se interponen en su camino, la mayor de las cuales es la recolección automática de basura que puede causar problemas de rendimiento intermitentes. Por lo tanto, es más fácil empezar a trabajar, pero puede ser más difícil obtener un desempeño lo suficientemente bueno. La interoperabilidad C parece fácil, aunque no lo he probado. Esta respuesta parece buena (respuesta principal en la búsqueda de google ‘C code from C #’): ¿Es posible llamar a una función C desde C # .Net?

Para responder a su última pregunta quizás debería estar mirando QT.

C ++ / CLI es bueno para pegar cosas nativas y cosas de .NET, pero no es simple incluso para progtwigdores de C ++ experimentados (porque en realidad no es C ++).

A veces opino que si pudiéramos retrasar el tiempo, podría no haber un C #, ya que C ++ / CLI podría (haber) hecho el trabajo. Pero para cuando obtuvimos C ++ / CLI (Visual Studio 2005, Managed C ++ era horrible), C # ya era bastante exitoso.

Tendré que buscar la referencia, pero la orientación actual (o, al menos reciente) de Microsoft fue que ahora se pretende que C ++ / CLI solo se use para escenarios de “interoperabilidad”. Este es un paso bastante grande hacia los objectives iniciales cuando se introdujo C ++ / CLI por primera vez; originalmente estaba pensado para ser un lenguaje .NET de primera clase junto a C # y VB.NET.

Mi regla de oro es que si tengo que duplicar los archivos de encabezado en C #, entonces C ++ / CLI podría ser preferible. De lo contrario, si es un P / Invoke “simple” (cadenas, ints, dobles) a código no administrado, simplemente continúe con eso.

Esta idea de que una DLL de C es menos segura que una DLL de CLI, ¿de dónde proviene? Es completamente falso en mi mente. Los archivos DLL de C son mucho más difíciles de realizar ingeniería inversa que cualquier código IL.

He usado C ++ / CLI para interoperar con una biblioteca de C. También he usado las cosas de interoperabilidad de C # (también conocido como DllImport) para varios proyectos ( como este ). DllImport es infinitamente más fácil que C ++ / CLI. Y te permite mantener el objective “Cualquier CPU”; solo incluya una DLL nativa para cada plataforma de destino y cargue la correcta en tiempo de ejecución. El pinning en CLI es difícil de hacer bien. Terminas con un montón de intentar / finalmente tipo de cosas. Es una mezcla rara de operadores.