Probablemente sea una buena idea mantener los conceptos por separado.
En primer lugar, C++ es un lenguaje, y no especifica nada sobre a qué plataforma se debe dirigir. En principio, el código directo de C++ podría compilarse para el ensamblador nativo x86, bytecode de Java, MSIL o cualquier otra cosa que le interese. Creo que Adobe creó recientemente un compilador de C++ que genera código de bytes Flash.
En segundo lugar, con la típica indecisión, Microsoft ha creado dos lenguajes derivados de C++ que apuntan a .NET. Primero, crearon las "extensiones administradas para C++". Luego decidieron que era una mierda, lo abandonaron e intentaron fingir que nunca existió.
Ahora su mejor apuesta para .NET-style C++ se llama C++/CLI, pero no es C++. Extiende y cambia el idioma en varias formas no estándar. (Y creo que el comité estándar de C++ solicitó que cambien el nombre para evitar confusiones. Pero no lo hicieron)
Visual Studio 2005 y versiones posteriores admiten C++/CLI. (en "Agregar proyecto", se enumeran en Visual C++ -> CLR)
Sin embargo, (no creía que fuera así de simple, ¿verdad?), Microsoft lo ha vuelto a hacer. Después de especificar C++/CLI, que en realidad es un intento razonablemente bien diseñado para integrar C++ con CLI, se dieron cuenta de que prácticamente nadie lo usa. Resulta que incluso los programadores de C++ generalmente prefieren usar C# cuando están trabajando en .NET, y de otra manera, C++ nativo.
Así que ahora, se están enfocando en hacer interoperabilidad entre nativo C++ y .NET más simple y más potente. Sin embargo, C++/CLI no es probable que desaparezca. Funciona, y en algunos casos es útil. Simplemente no es el asesino de C++ que originalmente esperaban.
Visual Studio (desde siempre) también es compatible con aplicaciones nativas de C++, compiladas a código máquina x86, no contaminadas por .NET. Estos se enumeran en el cuadro de diálogo "Agregar proyecto" en Visual C++ -> Win32.
Así que si quieres aprender C++, tienes dos opciones: Aprender C++/CLI, que te limita a un lenguaje solo de MS que sí, genera MSIL en lugar de código de máquina nativo y requiere .NET para ejecutarse, y en general no vale la pena la molestia porque si vas a tomar una dependencia de .NET de todos modos, ¿por qué no escribir en C#?
O aprende C++ apropiado, que está completamente separado de .NET y no puede hacer referencia directamente a los ensamblados .NET.
El punto clave es que son idiomas separados. O compila como C++/CLI, lo que significa que el compilador le permitirá hacer referencia a ensamblados .NET y generará código MSIL, o compilará como C++, en cuyo caso el mundo .NET no existe.
Y, por último, una nota de precaución. A pesar de mi redacción anterior ("C++ correcto" y "no contaminado por .NET"), C++ no es "mejor". En muchos casos, tampoco es más rápido. C++ tiene el potencial para ser más rápido, pero depende mucho más del programador.
El compilador de C# convertirá casi cualquier cosa en un código razonablemente eficiente. C++, por otro lado, está lleno de trampas que harán que su código sea más lento que el equivalente C#.
http://blogs.msdn.com/ricom/archive/2005/05/10/416151.aspx y las entradas de blog que hace referencia son dignas de leer para cualquier persona interesada en el rendimiento de un código similar escrito en los dos idiomas.
Solo hay un área donde las aplicaciones C++ serán consistentemente más rápidas, y eso es en tiempo de inicio. una aplicación .NET puede tener que cargar el framework .NET y JIT el código MSIL, donde una aplicación nativa ... simplemente comienza.
Pero, aparte de eso, probablemente sea 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 salvarte de las ineficiencias que creas en tu código.
En una "cáscara de red" :) –