ES C++ convertido en MSIL?

Question

He sido un largo tiempo de C# y .Net developer, y han estado jugando con la idea de aprender c++.

Una de las principales razones por las que he estado pensando acerca de esto, es cuánto más rápido de C++ puede ser más de las aplicaciones que utilizan .Net framework.Pero estoy en lo cierto al suponer que si yo escribo un C++ aplicación en Visual Studio, y/o de referencia .Red de bibliotecas en una aplicación de C++ que, que C++ se convierte en MSIL (al igual que en C#) - y para ello me gustaría perder el beneficio de la codificación en ella?

Así que mi pregunta es, realmente, este:son C++ componentes de una aplicación de referencia .Net ensamblados compilados en la forma "tradicional", o comiled en MSIL?

Answer 1

Bueno, es un poco más complicado que eso. En realidad, hay dos versiones totalmente diferentes de .NET de soporte de C ++.

El viejo, extensiones administradas para C ++, era la única opción disponible en Visual C ++ 2002/2003. Está disponible en los nuevos compiladores bajo la opción / clr: oldSyntax. Es un poco torpe, ya que trata duro para integrar con el estándar C ++, por lo que todas las palabras clave nuevas (y hay muchos de ellos) tienen el prefijo de subrayado doble, etc. código generado por este compilador es una mezcla de código nativo y MSIL, apodado IJW "se simplemente funciona".

El nuevo, denominado C ++ / CLI, es un lenguaje limpio nuevo disponible en Visual C ++ 2005 y posteriores. Lo más importante, es compatible con varios modos de generación de código. La opción / clr genera de nuevo una mezcla IJW de código nativo y MSIL. / CLR: resultados puros en un gestionada única asamblea, aunque puede traducir los tipos nativos en las estructuras .net correspondiente. El código, por tanto, no puede ser de tipo seguro y se puede utilizar la aritmética de punteros, más o menos como C # con / inseguro. Y la más estricta de las opciones está / CLR:. Seguro, que produce con seguridad de tipos, verificable MSIL de sólo el montaje, exactamente como compilador de C # hace (sin / insegura, que es)

Para las diferencias entre MC ++ y C ++ / CLI, consulte Wikipedia .

Para la descripción de los modificadores del compilador, consulte MSDN .

PS. El byte de código .NET se llama ya sea MSIL (Microsoft Intermediate Language) o CIL (Common Intermediate Language). MIL puede representar capa de medios de Integración, la biblioteca de bajo nivel utilizado por indocumentado WPF y Vista Ventana Desktop Manager.

Answer 2

Es probablemente una buena idea para mantener los conceptos por separado.

En primer lugar, C++ es un lenguaje, y no especifica nada acerca de lo que la plataforma debe ser el objetivo.En principio, recto en C++ de código puede ser compilado a los nativos de ensamblador x86, bytecode de Java, MSIL o nada más que pensar.Creo que Adobe recientemente hizo un compilador de C++ que genera el Flash de código de bytes.

Segundo, con la típica indecisión, Microsoft ha creado dos en C++lenguajes derivados de la orientación .NET.En primer lugar, se hizo la "extensiones administradas para C++".Entonces decidieron que era una mierda, zanjó ella y trató de fingir que nunca existió.

Ahora su mejor apuesta .NET-estilo de C++ se llama C++/CLI, pero no es C++.Se extiende y cambia el idioma en un número de formas no estándar.(Y creo que el estándar de C++ comité pidió que se cambie el nombre para evitar confusiones.Pero no lo hicieron)

Visual Studio 2005 y la más reciente soporta C++/CLI.(en "Agregar proyecto", que están enumerados en Visual C++ -> CLR)

Sin embargo (no creo que era así de simple, ¿no?), Microsoft ha hecho de nuevo.Después de la especificación de C++/CLI, que en realidad es una razonablemente bien diseñado intento de integración de C++ con la CLI, se dieron cuenta de que prácticamente nadie la usa!Resulta que incluso los programadores de C++ por lo general, prefieren usar C# cuando se está trabajando .NET, y adecuada, C++ nativo de otra manera.

Así que ahora, están enfocados en hacer de interoperabilidad entre nativo C++ y .RED más simple y más potente.Sin embargo, en C++/CLI, no es probable que se vaya.Funciona, y en algunos casos es útil.No es sólo el C++-killer que originalmente se esperaba.

Visual Studio (desde siempre) también soporta nativo de las aplicaciones de C++, compilado a x 86 del código de la máquina, no contaminado por el .NET.Estos se enumeran en el "Agregar Proyecto" diálogo en Visual C++ -> Win32.

Así que si quieres aprender C++, usted tiene dos opciones:Aprender C++/CLI, que lo limita a un MS-único idioma que sí, genera MSIL en lugar de código máquina nativo, y requiere .NETO a ejecutar, y por lo general no vale la pena molestarse porque si usted va a tomar una dependencia .NET de todos modos, ¿por qué no escribir en C#?

O aprender adecuada de C++, que es totalmente independiente de .NET y no se puede hacer referencia directamente .NET asambleas.

La clave para llevar el punto es que son lenguajes distintos.Ya sea que usted compilar C++/CLI, lo que significa que el compilador le permitirá referencia .NET asambleas, y va a generar código MSIL, o compilar como C++, en cuyo caso la .NETO mundo no existe.

Y por último, una nota de precaución.A pesar de mi texto anterior ("adecuada C++" y "no contaminado por el .NET"), C++ no es "mejor".En muchos casos, no es más rápido que cualquiera.C++ tiene la potencial para ser más rápido, pero depende mucho más en el programador.

El compilador de C# va a convertir casi cualquier cosa en razonablemente eficiente de código.C++ por otro lado, está lleno de trampas que harán de su código más lento que el equivalente en C#.

http://blogs.msdn.com/ricom/archive/2005/05/10/416151.aspx y los posts de blog que hace referencia son la pena leer para quien tenga curiosidad sobre el rendimiento de similares código escrito en los dos idiomas.

Sólo hay una zona donde las aplicaciones de C++ va a ser consistentemente más rápido, y que en el tiempo de inicio.una .NET aplicación puede tener que cargar el .NET framework y JIT el código MSIL, donde una aplicación nativa...apenas comienza.

Pero aparte de eso, probablemente es un error suponer que C++ será más rápido.Es puede ser, porque le da un poco más de control.Pero por lo general, eso solo significa que el compilador es menos capaz de salvar de las ineficiencias que se crea en su código.

Answer 3

Este es una muy buena discusión sobre gestionado vs (si anticuado) C ++ no administrado.

En una cáscara de nuez, C ++ se puede ya sea administrado (compilado para MIL) o no administrado (compilado a código nativo).

Answer 4

Independientemente de sus razones para querer aprender C ++ siempre es bueno saber más idiomas ya que amplía su mente para el aprendizaje de C ++ es una lección valiosa en sí misma.

Con C ++ se puede ejecutar como una aplicación .NET C ++ / CLI o nativa. Es sólo un modificador de compilador en Visual Studio sin embargo, hay un buen montón de diferencias de sintaxis entre los dos. Yo personalmente creo que el aprendizaje de ambos sabores es útil.

¿Cuál elegir en sus proyectos depende un poco de las necesidades, por ejemplo, si su programa necesita interactuar otros módulos administrados como módulos escritos en C # es preferible utilizar C ++ / CLI para evitar algunas de conmutación toldo, entre el código administrado y no administrado.

Answer 5

Los componentes C ++ no pueden hacer referencia fácilmente ensamblados .NET (es necesario utilizar COM). De C ++ se compila en CIL y tiene el mismo perfil de rendimiento a C #.

C ++ es un 10% más rápido para el mismo nivel de optomization para la mayoría del código obstante C # toma la mitad el tiempo para escribir y depurar así que para la misma cantidad de tiempo que diría las optomizations que puede poner en su lugar haría C # más rápido. ..