Código puro y comprobable
Actualización: noviembre 2007
Para la programación .NET, Visual C++ admite la creación de tres distintos tipos de componentes y aplicaciones: mixto, puro y comprobable. Los tres están disponibles a través de la opción del compilador /clr (Compilación de Common Language Runtime).
Comentarios
Para obtener más información acerca de los ensamblados comprobables, vea:
Mixtos (/clr)
Los ensamblados mixtos (compilados con /clr), contienen partes administradas y no administradas, lo que les permite utilizar características .NET, pero conteniendo aún código no administrado. Esto permite actualizar aplicaciones y componentes para utilizar las características .NET sin tener que volver a escribir el proyecto completo. El uso de Visual C++ para mezclar código administrado y no administrado de este modo se denomina interoperabilidad de C++. Para obtener más información, vea Ensamblados mixtos (nativos y administrados) e Interoperabilidad nativa y de .NET.
Puro (/clr:pure)
Los ensamblados puros (compilados con /clr:pure) pueden contener tipos de datos nativos y administrados, pero sólo funciones administradas. Al igual que los ensamblados mixtos, los ensamblados puros permiten la interoperabilidad con archivos DLL nativos a través de P/Invoke (vea Utilizar un elemento PInvoke explícito en C++ (Atributo DllImport)), pero las características de interoperabilidad de C++ no están disponibles. Además, los ensamblados puros no pueden exportar funciones que son invocables desde funciones nativas, porque los puntos de entrada de un ensamblado puro utilizan la convención de llamada __clrcall.
Ventajas de /clr:pure
Mejor rendimiento: dado que los ensamblados puros sólo contienen MSIL, no hay ninguna función nativa y, por consiguiente, no es necesaria ninguna transición administrada/no administrada. (Las llamadas a funciones realizadas a través de P/Invoke son una excepción a esta regla).
Conocimiento de AppDomain: las funciones administradas y tipos de datos de CLR existen dentro de los Dominios de aplicación, lo que afecta a su visibilidad y accesibilidad. Los ensamblados puros tienen en cuenta el dominio (__declspec (appdomain) se supone para cada tipo), por lo que el acceso a sus tipos y funcionalidad desde otros componentes .NET es más fácil y más seguro. Como resultado, los ensamblados puros interoperan más fácilmente con otros componentes .NET que los ensamblados mixtos.
No se cargan en disco: los ensamblados puros se pueden cargar en memoria e incluso transmitir. Esto es esencial para utilizar los ensamblados .NET como procedimientos almacenados. Esto es diferente en los ensamblados mixtos, los cuales debido a una dependencia de los mecanismos de carga de Windows, deben estar en el disco para ejecutarse.
Reflexión: no es posible reflejar en aplicaciones ejecutables mixtas, mientras que los ensamblados puros admiten por completo la reflexión. Para obtener más información, vea Reflexión en C++.
Capacidad de control del host: como los ensamblados puros sólo contienen MSIL, se comportan de forma más predecible y flexible que los ensamblados mixtos cuando se utilizan en aplicaciones que alojen el CLR y modifiquen su comportamiento predeterminado.
Limitaciones de /clr:pure
Esta sección trata sobre características actualmente no admitidas por /clr:pure.
Las funciones no administradas no pueden llamar a ensamblados puros. Por consiguiente, los ensamblados puros no pueden implementar interfaces COM ni exponer devoluciones de llamada nativas. Los ensamblados puros no pueden exportar funciones a través de archivos __declspec(dllexport) o .DEF. A su vez, las funciones declaradas con la convención __clrcall no se pueden importar a través de __declspec(dllimport). Las funciones de un módulo nativo se pueden llamar desde un ensamblado puro, pero éste no puede exponer funciones nativas invocables, de modo que la funcionalidad en un ensamblado puro se debe exponer a través de funciones administradas en un ensamblado mixto. Vea Cómo: Migrar a /clr:pure para obtener más información.
En Visual C++ 2005, la compilación en modo puro no admite las bibliotecas ATL y MFC.
No se aceptan .netmodules puros como entrada del vinculador de Visual C++. Sin embargo, el vinculador acepta archivos .obj puros, y los archivos .obj contienen un supraconjunto de información incluido en netmodules. Vea .Archivos netmodule como entrada del vinculador para obtener más información.
No se admite la compatibilidad con COM del compilador (#import), ya que esto introduciría instrucciones no administradas en el ensamblado puro.
Las opciones de punto flotante para la alineación y el control de excepciones no son ajustables para los ensamblados puros. Como resultado, no se pueden utilizar __declspec(align). De esta forma, se representan algunos archivos de encabezado, como fpieee.h, que no es compatible con /clr:pure.
La función GetLastError en el PSDK puede presentar un comportamiento indefinido si se compila con /clr:pure.
Comprobable (/clr:safe)
La opción del compilador /clr:safe genera ensamblados comprobables, como los escritos en Visual Basic y C#, que cumplen los requisitos que permiten a common language runtime (CLR) garantizar que el código no infringe la configuración de seguridad actual. Por ejemplo, si la configuración de seguridad prohíbe a un componente escribir en disco, el CLR puede determinar si el componente comprobable cumple este criterio antes de ejecutar el código. El CRT no ofrece compatibilidad con los ensamblados comprobables. (La compatibilidad con el CRT para los ensamblados puros se logra a través de una versión pura de MSIL de la biblioteca en tiempo de ejecución de C).
Los ensamblados comprobables proporcionan estas ventajas sobre los ensamblados puros y mixtos:
Más seguridad.
Algunas situaciones la requieren (componentes SQL, por ejemplo).
Las versiones futuras de Windows exigirán cada vez más a los componentes y a las aplicaciones que sean comprobables.
Una desventaja es que las características de interoperabilidad de C++ no están disponibles. Los ensamblados comprobables no pueden contener ninguna función no administrada ni tipo de datos nativo, aun cuando el código administrado no haga referencia a ellos.
A pesar del uso de la palabra "safe", la compilación de aplicaciones con /clr:safe no significa que no haya errores; sólo significa que el CLR puede verificar la configuración de seguridad en tiempo de ejecución.
Independientemente del tipo de ensamblado, las llamadas realizadas desde ensamblados administrados a archivos DLL nativos vía P/Invoke se compilarán, pero puede que fallen en tiempo de ejecución dependiendo de la configuración de seguridad.
.gif "Nota") Nota: |
|---|
Existe un escenario de codificación que aprobará el compilador pero que dará como resultado un ensamblado no comprobable: llamar a una función virtual a través de una instancia de objeto mediante un operador de resolución de ámbito. Por ejemplo: MyObj -> A::VirtualFunction();. |