Compartir a través de

/clr Restricciones

  • Artículo

Tenga en cuenta las siguientes restricciones sobre el uso de /clr:

  • En un controlador de excepciones estructurado, hay restricciones sobre el uso de _alloca cuando se compila con /clr. Para obtener más información, vea _alloca.

  • El uso de comprobaciones de error en tiempo de ejecución no es válido con /clr. Para más información, vea Cómo: Utilizar comprobaciones nativas en tiempo de ejecución.

  • Cuando se usa /clr para compilar un programa que solo utiliza sintaxis de C++ estándar, se aplican estas directrices al usar un ensamblado alineado:

    • Puede producirse un error en el código de ensamblado alineado que presupone conocer el diseño de pila nativo, las convenciones de llamada fuera de la función actual u otra información detallada sobre el equipo, si ese conocimiento se aplica al marco de pila para una función administrada. Las funciones que contienen código de ensamblado alineado se generan como funciones no administradas, como si se encontraran en un módulo independiente que se compiló sin /clr.

    • No se admite el código de ensamblado alineado en las funciones que pasan los parámetros de función construidos en copia.

  • Las vprintf Funciones no se pueden llamar desde un programa compilado con /clr.

  • El naked __declspec modificador se omite en /clr.

  • La función de traductor establecida por _set_se_translatorafectará solo las capturas en código no administrado. Para más información, consulte Control de excepciones.

  • No se permite la comparación de punteros de función en /clr.

  • No se permite el uso de funciones que no se ajusten completamente al prototipo /clr.

  • Las siguientes opciones del compilador no se admiten en /clr:

  • No se admite la combinación de la _STATIC_CPPLIBdefinición del preprocesador (/D_STATIC_CPPLIB) y la opción del compilador /clr no se admite. Esto es así porque la definición haría que la aplicación se vincule con la biblioteca Estándar de C++ multiproceso, lo cual no se admite. Para obtener más información, vea /MD, /MT, /LD (Usar Biblioteca en tiempo de ejecución).

  • Cuando se usa /Zi con /clr, hay repercusiones en el rendimiento. Para obtener más información, vea /Zi.

  • Si se pasa un carácter ancho a una rutina de salida de .NET Framework sin especificar también /Zc:wchar_t o sin convertir el carácter a _wchar_thará que la salida aparezca como unsigned short int. Por ejemplo:

    Console::WriteLine(L' ')              // Will output 32.
Console::WriteLine((__wchar_t)L' ')   // Will output a space.

  • /GS se omite cuando se compila con /clr, a menos que una función se encuentre en #pragma unmanaged o si la función se debe compilar en código nativo, en cuyo caso el compilador generará la advertencia C4793 que está desactivada de manera predeterminada.

  • Vea /ENTRY los requisitos de la signatura de función de una aplicación administrada.

  • Las aplicaciones compiladas con /openmp y /clr solo se pueden ejecutar en un único proceso de appdomain. Para obtener más información, vea /openmp(Habilitar la compatibilidad con OpenMP 2.0).

  • Las funciones que toman un número variable de argumentos (varargs) se generarán como funciones nativas. Cualquier tipo de datos administrados en la posición de argumento variable se serializará a tipos nativos. Cualquier de los tipos System.String son en realidad cadenas de caracteres anchos, pero se serializan a cadenas de caracteres de un solo byte. Por lo que si un especificador printf es %S (wchar_t*), se serializará a una cadena %s en su lugar.

  • Cuando se usa la macro va_arg, se pueden obtener resultados inesperados al compilar con /clr:pure. Para obtener más información, vea va_arg, va_copy, va_end, va_start. Las opciones del compilador /clr:pure y /clr:safe han quedado en desuso en Visual Studio 2015 y no se admiten en Visual Studio 2017 y versiones posteriores. El código que tenga que ser "puro" o "seguro" deberá portarse a C#.

  • No debe llamar a ninguna función que pase por la pila para obtener información de los parámetros (argumentos de función) desde el código administrado. La capa P/Invoke hace que esa información esté más abajo en la pila. Por ejemplo, no compile proxy o código auxiliar con /clr.

  • Las funciones se compilarán en código administrado siempre que sea posible, pero no todos los constructos de C++ se pueden traducir a código administrado. Esta determinación se realiza función por función. Si no se puede convertir alguna parte de una función a código administrado, la función completa se convertirá a código nativo. En los siguientes casos se impide que el compilador genere código administrado:

    • Códigos thunk generados por el compilador o funciones auxiliares. Los códigos thunk nativos se generan para cualquier llamada de función a través de un puntero de función, incluidas las llamadas de función virtuales.

    • Funciones que llaman a setjmp o longjmp.

    • Funciones que usan ciertas rutinas intrínsecas para manipular directamente los recursos del equipo. Por ejemplo, si se usa __enable y __disable, _ReturnAddress y _AddressOfReturnAddress, o elementos intrínsecos multimedia, todos darán como resultado código nativo.

    • Funciones que siguen la directiva #pragma unmanaged. (Lo contrario también se admite #pragma managed).

    • Una función que contiene referencias a tipos alineados, es decir, tipos declarados usando __declspec(align(...)).

Consulte también