Managed C++ (C++/CLI) vs C#/VB.NET

Question

He trabajado extensamente con C#, sin embargo, estoy comenzando un proyecto en el que nuestro cliente desea que todo el código se escriba en C++ en lugar de C#. Este proyecto será una combinación entre managed (.NET 4.0) y C++ nativo. Siendo que siempre he preferido C# a C++ para mis necesidades de .NET, me pregunto si hay alguna diferencia importante que pueda no tener en cuenta entre el uso de C# y el C++ administrado.

Cualquier apreciación de esto es muy apreciada.

EDIT Al mirar Wikipedia para el código de C++ administrado se muestra que la nueva especificación es C++/CLI, y que "C++ administrado" está en desuso. Actualizado el título para reflejar esto.

Answer 1

C++/CLI es un lenguaje .NET completo, y al igual que otros lenguajes .NET funciona muy bien en un contexto administrado. Del mismo modo que trabajar con llamadas nativas en C# puede ser un doloroso entrelazado C++ nativo y C++ administrado puede ocasionar algunos problemas. Dicho esto, si trabajas con mucho código C++ nativo, preferiría usar C++/CLI sobre C#. Hay bastantes errores que la mayoría podrían cubrirse al no escribir C++/CLI como si estuvieras escribiendo C# ni escribirlo como si estuvieras escribiendo C++ nativo. Es lo suyo.

He trabajado en varios proyectos de C++/CLI y el enfoque que tomaría realmente depende de la exposición de diferentes niveles de la aplicación al código nativo de C++. Si la mayoría del núcleo de la aplicación es nativa y el punto de integración entre el código nativo y el código administrado es un poco confuso, entonces usaría C++/CLI en todo momento. El beneficio del control en C++/CLI superará sus problemas. Si tiene puntos de interacción claros que podrían adaptarse o abstraerse, le sugiero encarecidamente la creación de una capa puente C++/CLI con C# arriba y C++ debajo. La razón principal de esto es que las herramientas para C# son más maduras y más ubicuas que las herramientas correspondientes para C++/CLI. Dicho esto, el proyecto en el que he estado trabajando ha sido exitoso y no fue la pesadilla que el otro señaló.

También me aseguraría de que comprenda por qué el cliente va en esta dirección. Si la idea es que tengan un grupo de desarrolladores de C++ y quieran simplificar el proceso de escribir código administrado, yo postularía al cliente que aprender C# puede ser menos desafiante que aprender C++/CLI.

Si el cliente cree que C++/CLI es más rápido, simplemente es incorrecto ya que todos compilan hasta IL. Sin embargo, si el cliente tiene una gran cantidad de desarrollo de C++ nativo existente o en curso, la ruta actual puede ser la mejor.

Answer 2

He hecho un proyecto con C++/CLI y tengo que decir que era una abominación. Básicamente era una aplicación WinForms para administrar empleados, juegos de hockey, intercambios entre equipos, calendarios, etc. ...

Así que puedes imaginar el número de controles administrados que tenía en mis formularios: calendarios/selectores de fecha y hora, combo cajas, cuadrículas, etc.

Lo peor fue usar solo tipos C++ para mi back-end, y usar los tipos administrados para el front-end. En primer lugar, no puede asignar una cadena estándar a una cadena administrada. Necesitarás convertir todo. Obviamente tendrá que convertirlo de nuevo ...

Cada vez que necesitaba llenar una grilla, serialicé mis colecciones C++ a algo así como un vector<std::string>, lo recupere en mi biblioteca de IU y luego lo bifurqué y lo hice nuevo DataGridRow para agregarlos a la grilla. Lo que obviamente se puede hacer en 3 minutos con C# y algunos Linq a SQL.

Terminé con A + para esa aplicación, pero seamos honestos absolutamente apestado. No puedo imaginar lo patética que fue la aplicación de los demás para mí.

Creo que hubiera sido más fácil si hubiera usado List<Customer>^ (Lista administrada de algún objeto) en mi C++ en lugar de convertir siempre todo entre vectores de cadenas. Pero necesitaba mantener el C++ limpio de cosas administradas.

/pissedof

Answer 3

Desde el uso de las tres áreas (.NET, C++/CLI y C++), puedo decir que en todos los sentidos Yo prefiero usar .NET (a través de C# o VB.NET). Para las aplicaciones puede usar WinForms o WPF (el último de los cuales me parece mucho mejor, especialmente para aplicaciones que se ven mucho más fáciles de usar).

Un problema importante con C++/CLI es que no tiene todas las características agradables del lenguaje que obtiene en .NET. Por ejemplo, la palabra clave yield en C# y el uso de lambda (no creo que sea compatible con C++/CLI - no me detengo en eso).

Sin embargo, hay una gran ventaja de C++/CLI. Es decir que puede crear un puente para permitir que C# y C++ se comuniquen. Actualmente estoy trabajando en un proyecto en el que muchos cálculos matemáticos y algoritmos ya se han escrito (durante muchos años) en C++, pero la compañía quiere pasar a una interfaz de usuario basada en .NET. Después de investigar en varias soluciones, llegué a la conclusión de que C++/CLI era mucho mejor para esto. Un beneficio es que me permitió construir una API que, para un desarrollador .NET, se veía y funcionaba como un tipo .NET.

Para desarrollar la interfaz de una aplicación, sin embargo, realmente no recomendaría C++/CLI. Desde el punto de vista de la usabilidad (en términos de tiempo de desarrollo cuando se usa) simplemente no vale la pena.Un gran problema es que VS2010 dropped support for IntelliSense for C++/CLI para "mejorar IntelliSense general" (creo específicamente para C++). Si aún no lo ha probado, definitivamente le aconsejo que consulte las aplicaciones de WPF.