Windows8でC＃/ XAMLとC ++ / XAML WinRTアプリケーションを作成することの長所と短所は何ですか？
WPF/SilverlightコンポーネントをWindows8に移植するルートをたどりたいのですが、少し文脈上、コンポーネントは リアルタイムWPFチャート であり、WPF /の混合を使用します。高いパフォーマンスを実現するためのXAMLおよびビットマップレンダリング。
コンポーネントをMetro互換にしたいのですが。メトロモードとデスクトップモードで使用されます。 Windows 8での C++/WinRT アプリケーションの作成と C＃/ XAML アプリケーションの作成についてよく読みましたが、2つのフレームワークの違いは何ですか？
C++/XAMLではなくC＃/ XAMLを選択した場合、制限はありますか？また、.NET4.0のC＃/ XamlからWindows8への移植は、C＃/ XAMLに固執できればはるかに簡単になると考えてください。ただし、この方法を使用して完全な機能を備えたMetroコンポーネントを作成できますか？
あなたのコメント/提案は大歓迎です。
編集：
このスレッドを閉じることに投票する場合は、その理由についてコメントを投稿してください。その有効な質問は、+ 6票、4つの回答、1つのお気に入りがあります。私にそれを保つのは合理的なようです！
私はその違いを、個人的な言語の好みではなく、デザインの選択だと考えています。設定は、VB vs C＃に関連します。一般的に、C++または.NETを選択するアプリケーションで得られる違いと同じです。
C++を使用すると、起動時間が短縮されます。 IIRC、.NET 4.5には自動NGEN機能があり（メトロアプリとの関連性は不明）、これは.NETアプリケーションの一般的な遅い起動時間を軽減するのに役立つ可能性があります。
C++は、ガベージコレクターを使用しないため、一般的なメモリ使用量が少なくなります。これは、タブレットなどのリソースに制約のあるデバイスでますます重要になります。 IIRC、.NET 4.5には、GCの一時停止（UIがちりばめられる可能性があります）に対する緩和策がありますが、マネージコードでは依然として現実的です。
.NETとC++は同じWinRTフレームワークを使用するため、XAML/WinRTプラットフォームとの対話にそれほど大きな違いはないでしょう（C++を介したWinRTオブジェクトとの対話は技術的に高速ですが、ヒットは非常に小さいです）が、もちろんユーザーコードは通常、.NETよりもC++の方が高速です。
C++は、難読化された.NETコードと比較した場合でも、一般にリバースエンジニアリングが困難です。ずる賢い泥棒は関係なくあなたのIPを盗むことができますが。
.NETは、開発者と開発者の生産性の利便性のために最初に作成されたため、アプリケーションの設計においてより便利なオプションがあります（たとえば、DI/IoCなどの反射ベースのツール）。
.NETはC++よりも高速にコンパイルされるため、アプリケーションコードの反復は、.NETを介して簡単になる場合がありますが、正しく作成されたC++プロジェクトでは、これを大幅に軽減できます。
純粋な.NETプロジェクトは「任意のCPU」をサポートできます。つまり、サポートされているすべてのWinRTプラットフォームでアプリケーションを実行できます。 C++プロジェクトでは、ARM、x86/64をサポートするために再コンパイルする必要があります。 .NETアプリケーションがカスタムC++コンポーネントに依存している場合は、アーキテクチャごとにコンパイルする必要があります。
WinRTは多くの言語をサポートするためにゼロから作成されたため、C++に慣れていない開発者への私の提案は、.NETに固執するが、C++の恩恵を受ける領域を探索することです。 Microsoftは/ CXプロジェクションで素晴らしい仕事をしており、ほとんどのC＃開発者は自分たちの道を見つけることができるはずです。 C++開発者への私の提案は、C++に固執し、C++のすべての利点を活用することです。
[〜＃〜] xaml [〜＃〜]の観点からは、言語の選択になります。 XAML UIスタックは、ここで選択したコード言語に関係なく同じです。アプリの目標によっては、その言語が提供するメリットが必要な場合は、C++を使用する方が理にかなっている場合があります。
また、Win8でDirectXとXAMLを混在させることもできます。これは通常、C++を意味しますが、SharpDXのようなプロジェクトでは、まだ完全には有効ではありません（はい、マネージコードでラップするためにDirectXでパフォーマンスヒットを支払うことになります...私はそれができることを指摘しているだけです）。
あなたの質問は、デスクトップとメトロで使用できる再利用可能なコンポーネントの作成に関するもののようです。これは、組み込みリソースではなくファイルの場所からリソース（generic.xamlなど）をロードする方法にいくつかの変更が必要だったため、アーキテクチャの方法によっては少し難しい場合があります。
C++/XAMLを使用することで私が考えることができる唯一の利点は、プロジェクトにとって速度が重要であるかどうかです。 C＃/ XAMLの利点は、特にプロジェクトがすでにC＃である場合、コーディングがはるかに簡単になることです。
今のところ、Windows8でMetroとデスクトップの両方を対象とするアプリケーションを作成する方法はありません。
お役に立てれば。
他の人はもっと知っているかもしれませんが、 WinRTの発表時間の前後に私が提起した質問に対するMicrosoftの回答 に基づいています：
WinRTは、プロトコルおよびネイティブAPIのセットであり、各言語を既存の実行環境（JavaScriptの場合はChakra、C＃の場合はCLR、C++の場合はCRT/rawネイティブコード）に忠実に保つことができます。
そのは、本質的にネイティブコードAPI（WinRT）にアクセスするためにCLRとネイティブコードを使用して現在経験しているものと同様のパフォーマンスのトレードオフを示唆しています。しかし、WinRTがどれほど異なるかを確認するために、これに関するいくつかの経験的調査を見るのを楽しみにしています。