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

  • /clr を使用して、標準の C++ 構文のみを使用するプログラムをコンパイルする場合は、インライン アセンブリの使用に次のガイドラインが適用されます。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.

    • コピーで構築された関数のパラメーターを渡す関数内のインライン アセンブリ コードはサポートされていません。Inline assembly code in functions that pass copy-constructed function parameters is not supported.

  • /clr でコンパイルされたプログラムから Vprintf 系関数を呼び出すことはできません。The vprintf Functions cannot be called from a program compiled with /clr.

  • /clr では naked __declspec 修飾子は無視されます。The naked __declspec modifier is ignored under /clr.

  • _set_se_translator で設定された変換関数は、アンマネージド コード内のキャッチにのみ影響を与えます。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.

  • /clr/Zi を使用すると、パフォーマンスに影響を与えます。When using /Zi with /clr, there are performance implications. 詳細については、「/Zi」を参照してください。For more information, see /Zi.

  • /Zc:wchar_t を一緒に指定せずに、またはこの文字を __wchar_t にキャストせずに、ワイド文字を .NET Framework 出力ルーチンに渡すと、出力が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 でコンパイルされたアプリケーションは、1 つの 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.

  • 可変個引数 (vararg) を受け取る関数は、ネイティブ関数として生成されます。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 型は、実際にはワイド文字の文字列ですが、1 バイト文字の文字列にマーシャリングされます。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