This documentation is archived and is not being maintained.

24.1 Effects of the /clr Switch

Visual Studio .NET 2003

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 __asm blocks.
  • 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 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. (Note that the inverse, #pragma managed, is also supported.)
  • A function that contains references to aligned types, that is, types declared using __declspec(align(...)).

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.)

See Also

Managed Extensions for C++ Programming | /clr (Common Language Runtime Compilation)