/clr 제한/clr Restrictions

/clr 사용 시 다음과 같은 제한 사항이 적용됩니다.Note the following restrictions on the use of /clr:

  • 정형 예외 처리기는 /clr을 사용하여 컴파일할 때 _alloca 사용에 대한 제한이 있습니다.In a structured exception handler, there are restrictions on using _alloca when compiling with /clr. 자세한 내용은 _alloca를 참조하세요.For more information, see _alloca.

  • /clr을 사용한 런타임 오류 확인은 유효하지 않습니다.The use of run-time error checks is not valid with /clr. 자세한 내용은 방법: 네이티브 런타임 검사 기능 사용을 참조하세요.For more information, see How to: Use Native Run-Time Checks.

  • 표준 C++ 구문만 사용하는 프로그램을 컴파일하기 위해 /clr을 사용하는 경우 인라인 어셈블리 사용 시 다음 지침이 적용됩니다.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. 인라인 어셈블리 코드를 포함하는 함수는 마치 /clr 없이 컴파일된 별도의 모듈에 배치된 것처럼 비관리형 함수로 생성됩니다.Functions containing inline assembly code are generated as unmanaged functions, as if they were placed in a separate module that was compiled without /clr.

    • copy-constructed 함수 매개 변수를 전달하는 인라인 어셈블리 코드는 지원되지 않습니다.Inline assembly code in functions that pass copy-constructed function parameters is not supported.

  • vprintf 함수/clr로 컴파일된 프로그램에서 호출할 수 없습니다.The vprintf Functions cannot be called from a program compiled with /clr.

  • naked __declspec 한정자는 /clr 아래에서 무시됩니다.The naked __declspec modifier is ignored under /clr.

  • _set_se_translator로 설정된 변환기 함수는 비관리 코드의 catch에만 적용됩니다.The translator function set by _set_se_translator will affect only catches in unmanaged code. 자세한 내용은 예외 처리를 참조하세요.See Exception Handling for more information.

  • /clr 아래에서 함수 포인터를 비교할 수 없습니다.The comparison of function pointers is not permitted under /clr.

  • 완전히 프로토타입화되지 않은 함수는 /clr 아래에서 사용할 수 없습니다.The use of functions that are not fully prototyped is not permitted under /clr.

  • 다음 컴파일러 옵션은 /clr을 지원하지 않습니다.The following compiler options are not supported with /clr:

  • _STATIC_CPPLIB 전처리기 정의(/D_STATIC_CPPLIB)와 /clr 컴파일러 옵션의 조합은 지원되지 않습니다.The combination of the _STATIC_CPPLIB preprocessor definition (/D_STATIC_CPPLIB) and the /clr compiler option is not supported. 이 정의는 애플리케이션이 정적 다중 스레드 C++ 표준 라이브러리에 연결하게 만드는데, 이는 지원되지 않습니다.This is so because the definition would cause your application to link with the static multithreaded C++ Standard Library, which is not supported. 자세한 내용은 /MD, /MT, /LD(런타임 라이브러리 사용) 토픽을 참조하세요.For more information, see the /MD, /MT, /LD (Use Run-Time Library) topic.

  • /Zi/clr에 사용하면 성능에 영향이 있습니다.When using /Zi with /clr, there are performance implications. 자세한 내용은 /Zi를 참조하세요.For more information, see /Zi.

  • /Zc: wchar_t 를 지정 하지 않고 .NET Framework 출력 루틴에 와이드 문자를 전달 하는 경우 (으)로 문자를 캐스팅 하지 않고 __wchar_t 출력이로 표시 되도록 unsigned short int 합니다.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.
    
  • 함수가 #pragma unmanaged 아래에 있거나 네이티브로 컴파일되지 않는 한, /clr로 컴파일할 때 /GS가 무시되며, 이 경우 컴파일러가 기본적으로 해제되는 C4793 경고를 생성합니다./GS is ignored when compiling with /clr, unless a function is under #pragma unmanaged or if the function must be compiled to native, in which case the compiler will generate warning C4793, which is off by default.

  • 관리형 애플리케이션의 함수 시그니처 요구 사항에 대한 /ENTRY를 참조하세요.See /ENTRY for function signature requirements of a managed application.

  • /openmp/clr로 컴파일된 애플리케이션은 단일 appdomain 프로세스에서만 실행할 수 있습니다.Applications compiled with /openmp and /clr can only be run in a single appdomain process. 자세한 내용은 /openmp(OpenMP 2.0 지원 활성화)를 참조하세요.See /openmp (Enable OpenMP 2.0 Support) for more information.

  • 가변 인수 번호(varargs)를 사용하는 함수는 네이티브 함수로 생성됩니다.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. System.String 형식은 실제로 와이드 문자 문자열이긴 하지만, 단일 바이트 문자열로 마샬링됩니다.Note that System.String types are actually wide-character strings, but they are marshaled to single-byte character strings. 따라서 printf 지정자가 %S(wchar_t*)인 경우 %s 문자열으로 마샬링합니다.So if a printf specifier is %S (wchar_t*), it will marshal to a %s string instead.

  • va_arg 매크로를 사용하는 경우 /clr:pure로 컴파일할 때 예기치 않은 결과가 발생할 수 있습니다.When using the va_arg macro, you may get unexpected results when compiling with /clr:pure. 자세한 내용은 va_arg, va_copy, va_end, va_start를 참조하세요.For more information, see va_arg, va_copy, va_end, va_start. /clr:pure/clr:safe 컴파일러 옵션은 Visual Studio 2015에서는 더 이상 사용되지 않으며 Visual Studio 2017 이상에서는 지원되지 않습니다.The /clr:pure and /clr:safe compiler options are deprecated in Visual Studio 2015 and unsupported in Visual Studio 2017 and later. “순수” 또는 “안전”해야 하는 코드는 C#으로 포팅해야 합니다.Code that must be "pure" or "safe" should be ported to C#.

  • 관리 코드에서는 스택을 탐색하여 매개 변수 정보(함수 인수)를 얻는 함수를 호출하면 안 됩니다. P/Invoke 레이어는 이 정보를 스택의 더 아래쪽에 배치합니다.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. 예를 들어 프록시/스텁을 /clr로 컴파일하지 마세요.For example, do not compile proxy/stub with /clr.

  • 가능한 경우에는 함수가 관리 코드로 컴파일되지만, 모든 C++ 구문을 관리 코드로 변환할 수 있는 것은 아닙니다.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.

    • setjmp 또는 longjmp를 호출하는 함수Functions that call setjmp or longjmp.

    • 특정 내장 루틴을 사용하여 머신 리소스를 직접 조작하는 함수.Functions that use certain intrinsic routines to directly manipulate machine resources. 예를 들어 __enable__disable, _ReturnAddress_AddressOfReturnAddress 또는 멀티미디어 내장 함수를 사용하면 모두 네이티브 코드가 됩니다.For example, the use of __enable and __disable, _ReturnAddress and _AddressOfReturnAddress, or multimedia intrinsics will all result in native code.

    • #pragma unmanaged 지시문을 따르는 함수.Functions that follow the #pragma unmanaged directive. (반대로 #pragma managed도 지원됩니다.)(Note that the inverse, #pragma managed, is also supported.)

    • 정렬된 형식, __declspec(align(...))을 사용하여 선언된 형식을 포함하는 함수A function that contains references to aligned types, that is, types declared using __declspec(align(...)).

참고 항목See also