For the latest documentation on Visual Studio 2017 RC, see Visual Studio 2017 RC Documentation.
Note the following restrictions on the use of /clr:
In a structured exception handler, there are restrictions on using
_allocawhen compiling with /clr. For more information, see _alloca.
The use of run-time error checks is not valid with /clr. For more information, see Run-Time Error 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 is not supported.
The vprintf Functions cannot be called from a program compiled with /clr.
The comparison of function pointers is not permitted under /clr.
The use of functions that are not fully prototyped is not permitted under /clr.
The following compiler options are not supported with /clr:
The combination of the
_STATIC_CPPLIBpreprocessor definition (
/D_STATIC_CPPLIB) and the /clr or /clr:pure compiler option is not supported. This is so because the definition would cause your application to link with the static multithreaded Standard C++ Library, which is not supported. For more information, see the /MD, /MT, /LD (Use Run-Time Library) topic.
/J is not supported with /clr:safe or /clr:pure.
The ATL and MFC libraries are not supported by pure mode compilation (/clr:pure). You can use /clr:pure with the Standard C++ Library and the CRT if you also compile with /MD or /MDd.
When using /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_twill 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
#pragmaunmanaged or if the function must be compiled to native, 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. See /openmp (Enable OpenMP 2.0 Support) for more information.
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. Note that System.String types are actually wide-character strings, but they are 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.
If your application passes an argument of type va_list to a function declared to take a variable number of arguments, and your application is compiled with /clr:pure, the CLR throws NotSupportedException. If /clr is used instead, the affected functions are compiled to native code and execute properly. If /clr:safe is used, an error diagnostic is emitted.
You should not call, from managed code, any functions that walk the stack to get parameter information (function arguments); the P/Invoke layer causes that information to be further down the stack. For example, do not 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 cannot 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
Functions that use certain intrinsic routines to directly manipulate machine resources. For example, the use of
_AddressOfReturnAddress, or multimedia intrinsics will all result in native code.
Functions that follow the
#pragma unmanageddirective. (Note that the inverse,
#pragma managed, is also supported.)
A function that contains references to aligned types, that is, types declared using
You cannot use the Compiler COM Support classes with /clr:pure or /clr:safe.