c# - WinRT が管理されていないのはなぜですか?

Question

Windows 8 では、.NET に似ていますが管理されていない WinRT が導入されています。管理されていないのはなぜですか？パフォーマンスの問題ですか？低レベルの API にはガベージ コレクションが適していないということですか。

Answer 1

WinRT は、古くからある C ベースの Winapi に代わるものです。これは、多くのランタイム環境で使用できなければならない API です。20 年前までは、C API との相互運用は比較的簡単でした。それ以降、COM は 1990 年代後半に普遍的な接着剤になりました。Windows で一般的に使用されているほとんどすべての言語ランタイムが COM をサポートしています。

ガベージ コレクターは、言語ランタイムの実装の詳細です。たとえば、.NET のコレクターは、Javascript のコレクターとは大きく異なります。いずれかで作成されたネイティブ オブジェクトは、コレクターの非常に厳格な規則に従う必要があります。つまり、各言語ランタイムに固有の WinRT バージョンを作成する必要がありました。Microsoft のような大企業でさえ、すべての言語バインディングに対して特定の WinRT バージョンを作成してサポートする余裕はありません。これらの言語は既に COM をサポートしているため、必要ではありません。

現在、WinRT の最適なバインディングは C++ です。これは、COM が明示的なメモリ管理により効率的に動作するためです。それを自動化する新しい C++ コンパイラ拡張機能からの十分な助けを借りて、それを回避するために C++/CLI のような構文を持つ古い _com_ptr_t に非常に似ています。CLR には既に優れた COM 相互運用機能がサポートされているため、マネージ言語へのバインドは比較的簡単です。WinRT も .NET のメタデータ形式を採用しました。残念ながら、今日の時点でマネージ コンパイラに関する作業はまったく行われていません。

編集: 有名な Microsoft プログラマー兼ブロガーである Larry Osterman は、削除された回答にかなり良いコメントを残しました。保存するためにここに引用します。

OS がアンマネージドであるため、WinRT はアンマネージドです。また、WinRT を設計どおりに設計することで、C++、C#、JS だけでなく、さまざまな言語で表現できるようになります。たとえば、デスクトップで動作する WinRT API を実装する一連の Perl モジュールを簡単に確認できました。もし.Netで実装していたら、それは非常に困難だったでしょう

Answer 2

WinRT は、Win32 (開発者がアクセスできる Windows 用の最下位レベルの API) の代替となることを目的としているため、管理されていません。アンマネージ API は依然として、開発者に公開できる可能性のある最もパフォーマンスの高い API であり、その上にマネージ API をラップすることは常に可能であり、それはまさに「プロジェクション」が行うことです。

また、C++ 開発者は、C++/CLI が導入するフープをジャンプすることなく WinRT を使用できることも意味します ( https://www.stroustrup.com/bs_faq.html#CppCLIを参照)。 WinRT を使用したい。

本当の問題は、「なぜ COM が必要なのか?」ということです。なぜマイクロソフトはそれを発明しなければならなかったのですか？COM のすべての機能が追加されていない単純な C++ は、実際の OOP 作業には不十分であり、C++ が「移植性」を提供するという Stroustrup の主張は、実際の作業に照らして非常に不誠実です。https://webmechs.com/webpress/2011/11/09/c-versus-objective-c-as-api-substrate/を参照してください。