Skip to content

Latest commit

 

History

History
85 lines (48 loc) · 6.34 KB

clr-restrictions.md

File metadata and controls

85 lines (48 loc) · 6.34 KB
descriptiontitlems.datehelpviewer_keywordsms.assetid
Learn more about: /clr Restrictions
/clr Restrictions
03/02/2022
/clr compiler option [C++], restrictions
385f6462-2c68-46d6-810e-469553ead447

/clr Restrictions

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 xref:System.String?displayProperty=fullName 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

close