Restricciones de /clr
Actualización: noviembre 2007
Deben tenerse en cuenta las siguientes restricciones de uso de /clr:
En un controlador de excepciones estructurado, hay restricciones en el uso de _alloca al compilar con /clr. Para obtener más información, vea _alloca.
El uso de comprobaciones de errores en tiempo de ejecución no es válido con /clr. Para obtener más información, vea Comprobaciones de errores en tiempo de ejecución.
Cuando se utiliza /clr para compilar un programa que sólo utiliza la sintaxis de C++ estándar, son de aplicación las instrucciones siguientes para el uso de ensamblado en línea:
El código de ensamblado en línea que asuma conocimientos del diseño de pila nativo, convenciones de llamada externas a la función actual u otra información de bajo nivel acerca del equipo, puede fallar si dichos conocimientos se aplican al marco de pila de una función administrada. Las funciones que contienen código de ensamblado en línea se generan como funciones no administradas, como si se encontraran en un módulo independiente compilado sin /clr.
No se admite el código de ensamblado en línea en las funciones que pasan parámetros de función construidos en copias.
No se puede llamar a funciones vprintf desde un programa compilado con /clr.
El modificador naked__declspec no se tiene en cuenta bajo /clr.
La función de traductor definida por _set_se_translator sólo afecta a capturas del código no administrado. Vea Exception Handling under /clr para obtener más información.
La comparación de punteros a función no está permitida bajo /clr.
El uso de funciones sin prototipos bien definidos no está permitido bajo /clr.
Las opciones del compilador siguientes no se admiten con /clr:
/EHsc y /EHs (/clr implica /EHa (vea /EH (Modelo de control de excepciones)))
/fp:strict y /fp:except (vea /fp (Especificar comportamiento de punto flotante))
/ZI
No se admite la combinación de la definición del preprocesador _STATIC_CPPLIB (/D_STATIC_CPPLIB) y la opción del compilador /clr o /clr:pure. Esto es así porque la definición haría que su aplicación se vinculara con la Biblioteca estándar de C++ de multiproceso estático, lo cual no se admite. Para obtener más información, vea el tema /MD, /MT, /LD (Utilizar la biblioteca en tiempo de ejecución).
/J no se admite con /clr:safe o /clr:pure.
En Visual C++ 2005, la compilación en modo puro (/clr:pure) no admite las bibliotecas ATL y MFC. Puede utilizar /clr:pure con la Biblioteca estándar de C++ y el CRT si también compila con /MD o /MDd.
Si se utiliza /Zi con /clr, afecta al rendimiento. Para obtener más información, vea /Zi.
Si se pasa un carácter ancho a una rutina de resultados de .NET Framework sin especificar /Zc:wchar_t o sin convertir el carácter a __wchar_t, el resultado será un unsigned short int. Por ejemplo:
Console::WriteLine(L' ') // Will output 32. Console::WriteLine((__wchar_t)L' ') // Will output a space./GS no se tiene en cuenta si se compila con /clr, salvo que exista una función bajo #pragma unmanaged o que la función deba compilarse en versión nativa, en cuyo caso el compilador genera la advertencia C4793, que de forma predeterminada está desactivada.
Vea /ENTRY para conocer los requisitos para firmas de funciones de una aplicación administrada.
Las aplicaciones compiladas con /openmp y /clr sólo se pueden ejecutar en un proceso simple de AppDomain. Vea /openmp (Habilitar la compatibilidad con OpenMP 2.0) para obtener más información.
Las funciones que utilizan un número variable de argumentos (varargs) se generarán como funciones nativas. Cualquier tipo de datos administrado situado en la posición de argumento variable se empaquetará para su envío a un procedimiento remoto como tipo nativo. Observe que los tipos System.String son en realidad cadenas de caracteres anchos, pero se empaquetan como cadenas de caracteres de un solo byte. Por tanto, si un especificador de printf es %S (wchar_t*), se empaquetará en una cadena %s.
Si se utiliza la macro va_arg, podrían obtenerse resultados inesperados al compilar con /clr:pure. Para obtener más información, vea va_arg, va_end, va_start.
Desde código administrado, no se deben efectuar llamadas a funciones que recorren la pila para obtener información de parámetros (argumentos de funciones). La capa P/Invoke hace que la información esté más abajo en la pila. Por ejemplo, no compile proxy/stub con /clr.
Las funciones se compilarán a código administrado siempre que sea posible, pero no todas las construcciones de C++ se pueden traducir a código administrado. Esta determinación se realiza para cada función independientemente. Si alguna parte de una función no se puede convertir a código administrado, entonces toda la función se convertirá a código nativo. Los casos siguientes evitan que el compilador genere código administrado.
Thunks generados por el compilador o funciones auxiliares. Los thunks nativos se generan para cualquier llamada a función a través de un puntero a función, incluso las llamadas a funciones virtuales.
Funciones que llaman a setjmp o longjmp.
Funciones que utilizan ciertas rutinas intrínsecas para manipular directamente recursos del equipo. Por ejemplo, el uso de __enable y __disable, _ReturnAddress y _AddressOfReturnAddress o intrínsecas multimedia producirá código nativo.
Funciones que siguen la directiva #pragma unmanaged. (Observe que también se admite la inversa, #pragma managed).
Una función que contiene referencias a tipos alineados, es decir, tipos declarados mediante __declspec(align(...)).
No se pueden utilizar las clases Compiler COM Support con /clr:pure o /clr:safe.