WinRTが管理されていないのはなぜですか？[閉まっている]

164

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

c# .net windows-8 windows-runtime

— user380719
ソース

これは、それを閉じるのと同じくらい悪い呼び出しでした。あなたは今や参照と情報源を主張し、あなたは質問を閉じることによって以前にそれを断ち切りました。ここで、優れたソースを、それを扱っていたプログラマーから削除しました。

— ハンスパッサント2012

これは実用的なプログラミングの質問に対応していないため、私はトピックから外れました。それは単なる好奇心です。この質問の結果、コードを変更するプログラマはいないでしょう。

— Raymond Chen

@Kevその推論により、「地球はどのようにして形成されたのか？」それは多くの宗教的な憶測を集めたので、科学界では絶対にひどいものだったでしょう。この質問には良い答えがあります-それが悪い答えをたくさん集めているからといって、それが悪い質問であるとは限りません。しかし、本当に、この質問をP.SEに移すだけではどうですか。

— 宮坂零

@casperOneこれは多くの開発者にとって正当な「ホワイトボード」の質問です-決定のおそらく技術的な理由を知りたいので、同じ理由を他の場所にも適用できるようにします。ガベージコレクターのプロファイリングが難しいためでしょうか。それは、低レベルのハードウェア抽象化へのアクセスが容易になるためでしょうか？技術的な理由がない場合、それは単に残念なことですが、それ自体は質問自体の質とは何の関係もありません。

— 宮坂零

@HansPassantに同意します。この質問を再度開いて、有効なものとして扱う必要があります。「なぜ管理されていないのですか？」WinRTの基礎に関して非常に良い質問です。

— Rob Perkins

回答:

190

WinRTのは、交換古来のCベースのWINAPIため。これは、多くのランタイム環境で使用可能でなければならないAPIです。20年前、C apiは比較的簡単に相互運用できました。それはその後も続いており、COMは1990年代後半にユニバーサルグルーになりました。Windowsで一般的に使用されているほとんどの言語ランタイムは、COMをサポートしています。

ガベージコレクターは、言語ランタイム実装の詳細です。.NETのコレクターは、たとえばJavaScriptのコレクターとは大きく異なります。どちらかで作成されたネイティブオブジェクトは、コレクターの非常に厳密な規則を遵守する必要があります。つまり、各言語ランタイムに固有のWinRTバージョンを作成する必要があったことになります。マイクロソフトほどの規模の企業であっても、すべての言語バインディングに対して特定のWinRTバージョンを作成してサポートする余裕はありません。これらの言語がすでにCOMをサポートしていることを考えると、必要もありません。

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

編集：有名なマイクロソフトのプログラマーでありブロガーであるラリー・オスターマンは、削除された回答にかなり良いコメントを残しました。保存するためにここで引用します。

OSが管理されていないため、WinRTは管理されていません。そして、WinRTを設計された方法で設計することにより、C ++、C＃、JSだけでなく、さまざまな言語で表現できるようになります。たとえば、デスクトップで動作するWinRT APIを実装するPerlモジュールのセットを簡単に見ることができます。.Netで実装した場合、それは非常に困難でした。

— ハンス・パッサント
ソース

コンパイラについては知りませんが、WinRT .NETプロジェクションでCLRに対して多くの作業が行われたと確信しています。それらはCOM相互運用コードを再利用した可能性がありますが、違いもありIInspectableます（たとえば、オブジェクトに実際のクラスタイプまたはサポートされているすべてのインターフェイスのリストをクエリするなどの操作を実行できます。また、winmdファイルを使用すると、そのすべてのWinRTメタデータをReflectionに投影できます。）。また、winmdファイルは相互運用機能アセンブリとしてすぐには使用できません。CLRはそれらを特別に処理する必要があります。

— Pavel Minaev 2011

確かに、あなたは象を無視しています。IInspectableは、1997年に行き詰まったIDispatchの代替品です。Microsoftで働いています。ここに秘密をいくつか教えてください：

— Hans Passant

言語予測をサポートするために、3つの言語すべてで行われた作業がありました。

— ReinstateMonica Larry Osterman

今のところ「WinRTの最適なバインディング」は実際にはC＃だと主張します。CLRバインディングはかなり高速のCOM相互運用機能を超えて最適化されており、開発プレビューの.NET言語は、「待機」機能を備えたユビキタス非同期機能の優れたサポートを実装しています。いくつかのデモでは、C＃コードはC ++サンプルよりもはるかに多く、より簡単に機能しました。多分後でC ++は非同期ヘルパー拡張を取得しますが、このバージョンではC ++非同期はひどく見えました。また、サイクル問題のあるC ++実装よりも、ガベージコレクションCLRから長期メモリをリークする可能性が低くなります。C＃FTW！

— Govert

@ハンス：3番目の射影は、すべてのCLR言語（主にC＃およびVB）のCLRです。また、WinJSはプロジェクションではなく、サポートライブラリのセットです。プロジェクションは、Chakra JSエンジンに直接組み込まれています。

— ReinstateMonica Larry Osterman '26 / 09/26

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

また、C ++開発者は、C ++ / CLIが導入するフープを飛び越えずにWinRTを使用できることも意味します（http://www2.research.att.com/~bs/bs_faq.html#CppCLIを参照）。 WinRTを使用する場合は、COMを学習する必要があります。

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

— Andz
ソース

C ++ / CLIに関するBjarneの考えの更新されたリンク： stroustrup.com/bs_faq.html#CppCLI