24.1 Effects of the /clr Switch
By default, the /clr compiler option is not in effect. When it is used, functions will be compiled to managed code whenever possible, but not all C++ constructs can be translated to managed code. Furthermore, 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.
- Functions containing
- Functions whose parameter lists use varargs/stdargs.
- 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
Another effect of the /clr compiler switch is the implication of the /MT compiler switch. This ensures that multithreaded versions of the runtime routines are selected from the standard header (.h) files. Multithreading is necessary for managed programming in part because the common language runtime garbage collector runs finalizers in an auxiliary thread. (See Section 4.3 for more information on finalizers.)
Managed Extensions for C++ Programming | /clr (Common Language Runtime Compilation)