¿C ++. Net se usa ampliamente?

Soy un codificador de C ++ por tradición. Durante los últimos 12 meses más o menos, he estado haciendo mucha codificación de C #, y me ha sorprendido gratamente el enfoque pragmático de C # (una vez que dejé de intentar codificarlo como si fuera "C ++ con recolección de basura").

Recientemente tuvimos algunos graduados y cuando ayudé a uno de ellos me di cuenta de que estaba usando .Net dentro de C ++. Después de preguntarle por qué, ella dijo que su gerente le había "dicho que usara C ++". Obvio problema de comunicación a un lado, supongo que estaba usando .Net porque ese es el único marco al que ha estado expuesta.

Luego me encontré con un antiguo proyecto de un desarrollador senior que también usaba C ++ para manejar un front-end de formularios. Ahora, esto se habría escrito alrededor del tiempo en que apareció .Net, así que supongo que fue un ejercicio de aprendizaje de su parte jugar con .Net. Era solo una pequeña aplicación de utilidad.

Habiendo tenido que hacer algunas modificaciones menores en esta aplicación, me pareció que usar C ++ para conducir .Net te da lo peor de ambos mundos. Sin recolección de basura o seguridad de la memoria, pero tampoco hay oportunidades reales de velocidad / optimización ya que se trata de un marco administrado.

Entonces, mi pregunta es si las personas usan C ++ .Net para cualquier código de producción grande independiente (es decir, sin plomería), y si es así, ¿cuáles son sus razones para hacerlo? Admito libremente que nunca he profundizado en las extensiones de C ++ .Net, por lo que puedo estar haciéndole un mal servicio.

C ++. NET (o, precisamente, C ++ / CLI) hace que la recolección de basura, al igual que todo lo demás que se ejecuta encima de .NET. Para lograr esto sin dejar de ser compatible con C ++ propiamente dicho, utiliza la ^sintaxis y gcnewlos punteros recolectados de basura ('seguros').

C ++ / CLI es considerado una abominación por muchos, es significativamente más desagradable trabajar con C # o C ++ propiamente dicho, y también es más complicado que cualquiera de ellos (simplemente porque aporta la complejidad de C ++ a la tabla y agrega lo que se necesita para trabajar con .NET a la mezcla). Aprender C # generalmente vale la pena incluso dentro del alcance de un solo proyecto de tamaño mediano. Sin embargo, hay una cosa que puede hacer que ni C # ni C ++ nativo pueden hacer: compilar C ++ existente contra .NET y hacer que se comunique con otros componentes .NET.

En consecuencia, no tiene mucho sentido usar C ++ / CLI para un proyecto desde cero: todo lo relacionado con .NET que se pueda hacer con él también se puede hacer en C #, con una sintaxis mucho mejor y la seguridad adicional de no exponer en bruto punteros por defecto. Su razón de ser más destacada es portar bases de código existentes a .NET. Una empresa que decide comenzar a usar .NET, pero no está dispuesta (o no puede hacerlo debido a limitaciones de recursos y tiempo) para reescribir cada pieza de software que ha producido hasta ahora, puede usar C ++ / CLI para seguir usando su base de código existente con solo cambios mínimos, y luego reescribe los componentes de su sistema en C # uno por uno. Al menos esa es la teoría; Nunca lo he visto hecho en la práctica, así que no puedo decir qué tan bien funciona.

También tenga en cuenta que C # en sí puede interactuar con bibliotecas nativas, por lo que incluso si tiene que usar bases de código C ++ existentes, no necesariamente tiene que volver a compilarlas con .NET: a menudo, interactuar con ellas a través de COM o P / Invoke es la mejor solución .