Escuché en alguna parte que Microsoft centrará sus esfuerzos en C# en lugar de C++ para la plataforma .NET. Puedo ver signos de que esto es cierto debido al diseñador de GUI que estaba disponible para C# pero no para C++.¿Está muriendo C++ .NET?
Así que me gustaría saber si en C++ .NET está muriendo y si seguirá siendo segundo a C# en el futuro.
Si el idioma de la plataforma .NET en el desarrollo de aplicaciones, entonces sí C++/CLI es un ciudadano de segunda clase en comparación con C#. C# se diseñó específicamente como el lenguaje para .NET framework, mientras tanto, la extensión C++/CLI está ahí para permitir a los desarrolladores unir código nativo y administrado.
Sin embargo no confunden C++ con C++/CLI (C++ .NET es lo mismo ...). C++ está vivo y bien en áreas como Kernel, juegos, alto rendimiento y aplicaciones de servidor (por ejemplo, servidor SQL), todas las cuales es poco probable que cambien. Por otro lado, la mayoría de las cosas de 'GUI .NET' no usarán C++.
No sabía que podía acceder al framework con C++ nativo (¿es por eso que dice que es lo mismo que C++ .NET?). – Unknown
Está diciendo que "C++ CLR" es lo mismo que "C++ .NET" – sharkin
Debe dar la marca/clr al compilador de C++ si desea utilizar código administrado y nativo en el mismo ensamblado. Básicamente, al agregar esta marca, el compilador agrega metadatos de .NET Framework al ensamblado. También puede usar/clr: safe y/clr: indicadores puros para generar ensamblajes .NET solo MSIL en cuyo caso C# y C++ son iguales aquí (lo mismo para VB.NET, J #, etc.). – Serguei
Managed C++ en realidad nunca llegó a ser lo que MS pensó que sería. C# podría hacer (casi) lo mismo, con una sintaxis mucho más intuitiva y fácil de usar.
Aparte de eso, C++/CLI no se dejará sin soporte durante mucho tiempo, ya que es la manera más fácil de crear interoperabilidad entre ensamblados .NET y ensamblajes nativos de C++. Sin embargo, eso es todo lo que se usa (estoy seguro de que hay un 0,001% de desarrolladores de C++/CLI que no están de acuerdo: P).
¿Entonces estás diciendo que no puedes hacer interoperabilidad entre C# y C++ nativo? Pensé que la cosa p/invoke es completamente utilizable en C# – Unknown
@ Desconocido, él no está diciendo que no puede, está diciendo que "C++/CLI es la manera fácil". No sé si estaría de acuerdo, sin embargo, porque nada en C++/CLI me parece fácil. –
C++/CLI es sorprendentemente fácil ... al menos, en comparación con volver a escribir los encabezados de SDK desde cero necesarios para utilizar P/Invoke. – Shog9
C++/CLI es la forma en que Microsoft atrae a los desarrolladores nativos de C++ a .NET. Era como una capa intermedia entre C++ nativo y C#, pero estoy bastante seguro de que los desarrolladores prefieren elegir C++ nativo o C#.
Microsoft no permitirá que C++/CLI morir, al menos en un futuro cercano, sin embargo, sin el apoyo de la comunidad, C++/CLI no será capaz de crecer.
En esta generación, no crecer significa estar a punto de morir.
Por otro lado, me parece que el mundo de la programación ha madurado mucho, y no espero un gran crecimiento en la próxima década. No hay ninguna razón por la cual una tecnología significativa no pueda sobrevivir durante mucho tiempo en una base de usuarios relativamente constante. –
Me temo que es.
La razón de esto no es C# (que no aporta nada especial y, aunque es un lenguaje nuevo, no da lugar a nuevas funciones de idioma, sino que simplemente copia características de otros, genéricos).
Es principalmente porque el primer intento de la EM para permitir C++ para la plataforma .NET - Managed C++ - fue un desastre.
Después de esto, contrataron Herb Sutter, gurú de C++, lo que hizo un trabajo fantástico al diseñar el reemplazo de C++ administrado llamado C++/CLI. Por qué y cuánto el diseño de C++/CLI es superior al diseño de C++ administrado se puede encontrar al leer A Design Rationale for C++/CLI escrito por Herb.
Por cierto, Herb hizo vc compilador de uno de los mejores compiladores que sigan los estándares para Windows después de años de que sea el peor en lo que se refiere a la conformidad estándar.
Creo que las extensiones administradas fueron bastante buenas, mejores que C++/CLI. Desafortunadamente, agregó extensiones divertidas y a la gente no le gustó eso, por lo que pusieron diferentes extensiones (suspiro) y rompieron la capacidad de consumir recursos administrados "nativamente" (es decir, en el montón nativo sin poner^en todas partes). Herb está bien, pero no creo que haya hecho un buen trabajo con C++/CLI. – gbjbaanb
¿Has leído "A Design Rationale for C++/CLI"? Por lo que dices Supongo que no has ... –
Er, gbjbaanb, si no me equivoco, los recursos gestionados nunca estuvieron en el montón nativo. El operador^se agregó para crear una distinción entre objetos administrados y no administrados, porque antes, los objetos administrados todavía estaban en el montón administrado, pero no había ninguna sintaxis para indicarlos. –
No creo que desaparezca necesariamente, pero la razón para usarlo casi siempre se reduce a si necesita o no los beneficios de rendimiento que conlleva. Si C# puede hacer lo mismo al 90% de la eficiencia de C++, ¿no es eso realmente lo suficientemente bueno?
No. Nació muerto.Siempre se ha tratado como una cita de segunda clase sin hoja de ruta de vitalidad.
Mayor vida útil, gracias a C++/CX cuya sintaxis es * muy * similar. Incluso agregaron soporte IntelliSense nuevamente. –