Extensiones administradas para C++

Las extensiones administradas para C++ o Managed C++ son un conjunto obsoleto de extensiones de lenguaje para C++ , que incluyen extensiones gramaticales y sintácticas, palabras clave y atributos, para llevar la sintaxis y el lenguaje C++ al .NET Framework . Estas extensiones fueron creadas por Microsoft para permitir que el código C++ se ejecute en Common Language Runtime (CLR) como código administrado , y que continúe interactuando con el código nativo.

En 2004, las extensiones de Managed C++ se revisaron significativamente para clarificar y simplificar la sintaxis y ampliar la funcionalidad para incluir genéricos administrados . Estas nuevas extensiones se denominaron C++/CLI y se incluyeron en Microsoft Visual Studio 2005. [ ^{1 ] Por} lo tanto, el término Managed C++ y las extensiones a las que se refiere están obsoletos y han sido reemplazados por las nuevas extensiones.

Microsoft introdujo las Extensiones Administradas para C++ en Microsoft Visual C++ 2002 (MSVC++). Microsoft intentó minimizar las diferencias entre el C++ estándar y las Extensiones Administradas para C++, lo que provocó que las diferencias fundamentales entre ambos quedaran sintácticamente ocultas. MSVC++ 2003 y 2005 también ofrecieron soporte para escribir programas en C++ administrado. En 2004, las Extensiones Administradas para C++ quedaron obsoletas en favor de C++/CLI , un segundo intento de Microsoft por admitir la programación para la Infraestructura de Lenguaje Común utilizando C++. ^{[ 2 ]}

El término "administrado" se refiere al código administrado que se ejecuta en la máquina virtual .NET , la cual funciona como un entorno aislado para una mayor seguridad mediante comprobaciones en tiempo de ejecución, como la detección de desbordamientos de búfer. Además, las aplicaciones escritas en C++ administrado se compilan a CIL (Lenguaje Intermedio Común) y no directamente a instrucciones nativas de la CPU, como ocurre con las aplicaciones C++ estándar.

El código C++ administrado puede interactuar con cualquier otro lenguaje también compatible con CLR , como C# y Visual Basic .NET , y aprovechar las características que ofrece CLR , como la recolección de basura . Esto significa que C++ administrado ocupa una posición única en el conjunto de lenguajes .NET. Es el único lenguaje que puede comunicarse directamente con lenguajes .NET (como C# y VB.NET), así como con C++ nativo. Los demás lenguajes .NET solo pueden comunicarse con código C++ mediante PInvoke o COM . Sin embargo, dado que C++ administrado puede comunicarse directamente tanto en contextos de C++ administrado como estándar, se utiliza a menudo como un puente.

Los programas escritos en Managed C++ ofrecen funcionalidades adicionales del .NET Framework y del CLR . La más destacada es la recolección de basura , que libera al programador de la gestión manual de la memoria. El recolector de basura (GC) es gestionado por el CLR. La gestión de la memoria se ejecuta con bastante rapidez, pero para aplicaciones que requieren un rendimiento óptimo, el código nativo no administrado suele ser la opción preferida.

C++ administrado está orientado a la programación orientada a objetos. Una diferencia importante entre C++ estándar y C++ administrado es que no admite la herencia múltiple , y una clase administrada por el recolector de basura de CLR no puede heredar de más de una clase. Esto se debe a una limitación de CLR.

Características principales:

• Metadatos extensibles: información que describe la estructura y los tipos de un componente administrado. Se pueden extender y reutilizar para crear componentes de software. Se utilizan ampliamente en C# y Visual Basic .NET.
• Recogida de basura: el CLR está totalmente gestionado por un recolector de basura para la gestión de memoria, automatizada por el propio CLR; es decir, no es necesario llamar al operador delete en el código C++ gestionado.
• Interoperabilidad con lenguajes .NET: el código destinado al .NET Framework produce una salida en Microsoft Intermediate Language (MSIL, similar al bytecode de Java) y, por lo tanto, los módulos compilados y los componentes (más bien ensamblados) pueden ser reutilizados por otros componentes de programas escritos en otro lenguaje destinado al .NET Framework, como JScript .NET, C#, Visual Basic .NET y otros lenguajes de terceros para .NET.
• Control de versiones: se pueden introducir nuevos métodos y miembros de datos en las clases gestionadas existentes sin romper la compatibilidad binaria con el software del lado del cliente existente.
• Encabezados binarios: permiten reutilizar metadatos precompilados; cualquier archivo .exe, .dll, .obj o .netmodule compilado en MSIL puede referenciarse desde un archivo fuente de C++.
• Protección contra desbordamiento de búfer: gracias a la introducción de la recolección de basura en C++, C++ administrado es menos propenso a los errores comunes de desbordamiento de búfer causados ​​por la ausencia de verificación de tipos de datos en C++ estándar. El recolector de basura ayuda a reducir (aunque no por completo) la frecuencia de estos errores.
• Biblioteca de clases base de .NET Framework : C++ administrado también tiene el potencial de ser menos verboso que el código estándar no administrado, ya que todas las llamadas a funciones administradas y las clases heredadas se derivan de la Biblioteca de clases base de .NET Framework (BCL, a veces denominada FCL o Biblioteca de clases de Framework), cuya API proporciona capacidades de red TCP/IP, funciones de manipulación de texto, acceso a datos (desde ODBC hasta SQL), servicios XML (desde XSD hasta XSL), programación de GUI (Windows Forms), servicios de correo (SMTP), criptografía (certificados X509 y firmas digitales XML), generación de MSIL (esencialmente, emisión de instrucciones en MSIL), E/S de archivos, manipulación manual del recolector de basura CLR e información de administración para manipular la consola WMI.

Los siguientes ejemplos ilustran el uso de C++ administrado en comparación con C++ estándar:

• (Cambio global) El código C++ existente que se vaya a portar a través de CLR debe ir acompañado de lo siguiente:

// Gello.cpp// nueva directiva using #using <mscorlib.dll>// otra directiva using namespace. using namespace System ;int main () { Console :: WriteLine ( "Hola, mundo!" ); return 0 ; }

Una nueva directiva de preprocesador

#usando <mscorlib.dll>

es necesario. Además de eso, se requieren más directivas #using para importar más bibliotecas para usar más espacios de nombres en la Biblioteca de Clases Base, como

#usando <System.Windows.Forms.dll>

y

using namespace System :: Windows :: Forms ;

para usar Formularios de Windows.

• Para compilar código que tenga como destino el CLR, es necesario introducir una nueva opción de compilador.

 cl.exe hello.cpp /clr

/clr permite que cualquier código que haga referencia a .NET Framework se compile como CIL .

• Se puede designar una clase para que sea recolectada como basura mediante la __gcpalabra clave de extensión.

// GarbageCollected.cpp#usando <mscorlib.dll>__gc clase GarbageCollected { int * i ; char * g ; float * j ; };int main () { while ( true ) { GarbageCollected ^ _gc = gcnew GarbageCollected (); } return 0 ; }

El código anterior se puede compilar y ejecutar sin temor a fugas de memoria . Dado que la clase gces administrada por el recolector de basura, no es necesario llamar al deleteoperador. Para lograr lo mismo con código no administrado, deletese requiere la palabra clave:

// NotGarbageCollected.cppclase NotGarbageCollected { int * i ; char * g ; float * j ; };int main () { while ( true ) { NotGarbageCollected * g = new NotGarbageCollected (); delete g ; } return 0 ; }

Notas:

• Una clase designada con __gc puede tener un constructor declarado.
• Una clase designada con __gc puede tener un destructor declarado.
• Una clase designada con __gc no puede heredar de más de una clase. (Esta es una limitación del CLR).
• Una clase designada con __gc no puede heredar de otra clase que no esté designada con __gc.
• Una clase designada con __gc no puede ser heredada por otra clase que no esté designada con __gc.
• Una clase designada como __gc puede implementar cualquier número de interfaces __gc.
• Una clase designada como __gc no puede implementar una interfaz no administrada.
• Una clase designada con __gc no se hace visible fuera de su propio ensamblado por defecto.

public __gc class MyClass { // ... };

la palabra clave pública para modificar el acceso de una clase designada con __gc.

Una clase designada con __gc puede destruirse manualmente utilizando la palabra clave delete, pero solo si la clase designada con __gc tiene un destructor definido por el usuario.

• Se puede declarar una interfaz anteponiéndole la palabra clave de extensión __gc. Por ejemplo:

// MyInterface.cpp #usando <mscorlib.dll>__gc __interface MyInterface { void init (); int common (); }

El código anterior debe compilarse con /clr y /LD para producir un archivo DLL simple.

Notas:

• Una interfaz __gc no puede contener miembros de datos, miembros estáticos, declaraciones de clases anidadas ni especificadores de acceso.
• Una interfaz __gc solo puede heredar de otra interfaz __gc o de System::Object. La herencia de System::Object es el comportamiento predeterminado.
• Una interfaz __gc no puede contener ninguna implementación (código base) de los prototipos de función declarados.

A continuación se exponen los puntos principales y los estándares de programación que diferencian a Managed C++ de otros lenguajes de programación conocidos que son similares en concepto.

public __gc class First { int i ; };public __gc class Second : private First { int h ; i = h ; }; // errorpublic __gc class Third : protected First { int h ; i = h ; }; // error

__gc class First {}; __gc class Second {}; __gc class Third : public First , public Second {}; // producirá un error

• C++/CLI

• Extensiones administradas para C++ (en MSDN)
• Artículo: C++ / CLI – ¿Cómo usar las DLL de C++ administrado cuando no está instalado Microsoft Visual C++ Redistributable?