Edit

Share via

/clr Restrictions

  • Article

Note the following restrictions on the use of /clr:

  • In a structured exception handler, there are restrictions on using _alloca when compiling with /clr. For more information, see _alloca.

  • The use of run-time error checks isn't valid with /clr. For more information, see How to: Use native run-time checks.

  • When /clr is used to compile a program that only uses standard C++ syntax, the following guidelines apply to the use of inline assembly:

    • Inline assembly code that assumes knowledge of the native stack layout, calling conventions outside of the current function, or other low-level information about the computer may fail if that knowledge is applied to the stack frame for a managed function. Functions containing inline assembly code are generated as unmanaged functions, as if they were placed in a separate module that was compiled without /clr.

    • Inline assembly code in functions that pass copy-constructed function parameters isn't supported.

  • The vprintf Functions can't be called from a program compiled with /clr.

  • The naked __declspec modifier is ignored under /clr.

  • The translator function set by _set_se_translator will affect only catches in unmanaged code. For more information, see Exception handling.

  • The comparison of function pointers isn't permitted under /clr.

  • The use of functions that aren't fully prototyped isn't permitted under /clr.

  • The following compiler options aren't supported with /clr:

  • The combination of the _STATIC_CPPLIB preprocessor definition (/D_STATIC_CPPLIB) and the /clr compiler option isn't supported. It's because the definition would cause your application to link with the static, multithreaded C++ Standard Library, which isn't supported. For more information, see /MD, /MT, /LD (Use Run-Time Library).

  • When you use /Zi with /clr, there are performance implications. For more information, see /Zi.

  • Passing a wide character to a .NET Framework output routine without also specifying /Zc:wchar_t or without casting the character to _wchar_t will cause the output to appear as an unsigned short int. For example:

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

  • /GS is ignored when compiling with /clr, unless a function is under #pragma unmanaged or if the function must be compiled as native code, in which case the compiler will generate warning C4793, which is off by default.

  • See /ENTRY for function signature requirements of a managed application.

  • Applications compiled with /openmp and /clr can only be run in a single appdomain process. For more information, see /openmp (Enable OpenMP 2.0 Support).

  • Functions that take a variable number of arguments (varargs) will be generated as native functions. Any managed data types in the variable argument position will be marshaled to native types. Any System.String types are actually wide-character strings, but they're marshaled to single-byte character strings. So if a printf specifier is %S (wchar_t*), it will marshal to a %s string instead.

  • When using the va_arg macro, you may get unexpected results when compiling with /clr:pure. For more information, see va_arg, va_copy, va_end, va_start. The /clr:pure and /clr:safe compiler options are deprecated in Visual Studio 2015 and unsupported in Visual Studio 2017 and later. Code that must be "pure" or "safe" should be ported to C#.

  • You shouldn't call any functions that walk the stack to get parameter information (function arguments) from managed code. The P/Invoke layer causes that information to be further down the stack. For example, don't compile proxy/stub with /clr.

  • Functions will be compiled to managed code whenever possible, but not all C++ constructs can be translated to managed code. This determination is made on a function-by-function basis. If any part of a function can't be converted to managed code, the entire function will be converted to native code instead. The following cases prevent the compiler from generating managed code.

    • Compiler-generated thunks or helper functions. Native thunks are generated for any function call through a function pointer, including virtual function calls.

    • Functions that call setjmp or longjmp.

    • Functions that use certain intrinsic routines to directly manipulate machine resources. For example, the use of __enable and __disable, _ReturnAddress and _AddressOfReturnAddress, or multimedia intrinsics will all result in native code.

    • Functions that follow the #pragma unmanaged directive. (The inverse, #pragma managed, is also supported.)

    • A function that contains references to aligned types, that is, types declared using __declspec(align(...)).

See also