MicrosoftはC++/CLI in .NET Core 3.1の提供計画を発表した。ターゲットとなるのはWindowsアプリケーションのみで、LinuxあるいはOSXでC++/CLIを使用することはできない。
C++/CLIは、.NETをターゲットとするC++バージョンを開発するMicrosoftの試みとしては2回目のものになる。2005年に開発されたものは、Managed Extensions for C++のリプレースとなった。目的は、従来のC++オブジェクトをマネージド(.NET)オブジェクトと自由に混在可能にすることだ。
最初に思い浮かぶユースケースは、相互運用性である。VBやC#からネイティブなDLLやCOMコンポーネントを呼び出すことは可能だが、これらのライブラリが提供するAPIは、VBやC#には必ずしも適していない。C++/CLIライブラリでラップすることによって、この非互換性を隠ぺいする抽象化が可能になるのだ。
別の用途として、ハードウェアの直接アクセスがある。ハードウェアを操作する場合には、アンマネージドなメモリを慎重に操作する必要のあることが多い。C#でも"unsafe"ブロックでこれを行うことが可能だが、制限された範囲でしかない。C++であれば、インラインアセンブリを使うことで、言語ベースの制限をすべて回避できる。
制限はある。Hans Passant氏が次のように説明している。
C++/CLIコンパイラは、マシンコードとIL、両方の生成をサポートしています。/clrを指定せずにコンパイルされたコード、あるいは#pragma managed(push, off)と#pragma managed(pop)で囲まれた関数は、マシンコードを生成します。あるいは、ILに変換できないコードを含むために、マシンコードにコンパイルしなければならない関数です。_asmなど、最初のスニペットでのC4973警告に注意してください。警告の抑制には#pragma managedを使用します。このようなコードでは、当然ですが、マネージド型を使用することはできません。
コード生成の単位は関数です。両方を必要とする関数は機能しません。main()関数はマネージド型を使用するので、ILにコンパイルする必要があります。マシンコードにコンパイルされる関数は、もちろん、インライン展開されることはありません。
Microsoft Visual C++コンパイラのターゲットがWindowsのみであるため、C++/CLIも同じようにWindowsのみで使用可能なのだと思われる。このようなネイティブコードとILコードの混在には、各オペレーティングシステムでプラットフォーム専用のコンパイラが必要になるはずだからだ。
ただしこれは、不可能な目標ではない。C++/CLIはECMA-372として標準化されているので、理屈の上からは、LLVMないしgccが拡張機能を採用して、LinuxあるいはOSX版を提供することは可能なはずだ。
その他のC++/.NET言語
C++/CLIは現在も有効なオプションだが、Microsoftの最後の試みにはならなかった。Windows 8とWinRTの開発の一環として、MicrosoftはC++/CXを開発している。文法上はC++/CLIに似ているが、WinRTバージョンのCOMで動作するように、特別に設計されている。
2015年に、C++/CXはC++/WinRTにリプレースされた。この記事で取り上げた他の言語とは違い、C++/WinRTはC++の拡張ではなく、C++ 11と14をベースとした"通常の"C++コードの記述で、WinRT/COMインフラストラクチャにアクセスすることが可能になっている。詳しい情報は、"CppCon 2016: Kenny Kerr & James McNellis “Embracing Standard C++ for the Windows Runtime"を参照して頂きたい。