在Windows8中編寫C＃/ XAML與C++/XAML WinRT應用程序有什麼優缺點？

Question

我想沿着將WPF/Silverlight組件移植到Windows 8的路線。有一點上下文，組件是real-time WPF Chart，它使用WPF/XAML和位圖呈現的混合來實現高性能。

我希望組件與Metro兼容，例如，在地鐵模式以及桌面模式下使用。我讀了很多關於在Windows 8以及C#/XAML應用程序中創建C++/WinRT應用程序的內容，但是這兩個框架之間有什麼區別？

如果您在C++/XAML上選擇C＃/ XAML，是否存在限制？另外考慮如果我堅持使用C＃/ XAML，從.NET4.0移植到Windows8的C＃/ Xaml會更容易，但是我能否使用此方法創建功能齊全的Metro組件？

您的意見/建議表示讚賞。

編輯：

如果你投票關閉這個線程，請發表評論爲什麼。它是一個有效的問題，有6票，4個答案和1個最愛。似乎合理的保留給我！

Answer 1

作爲一種設計選擇，我看到了這種差異，而不是個人的語言偏好。偏好會更關係到VB和C＃。一般來說，它與您在選擇C++或.NET的應用程序中獲得的差異相同。

C++將爲您提供更快的啓動時間。 IIRC，.NET 4.5具有自動NGENing功能（不知道它與城域應用程序的關係如何），因此這可能有助於緩解.NET應用程序的典型緩慢啓動時間。

由於C++不使用垃圾收集器，C++會降低一般內存使用量。這在平板電腦等資源受限的設備上變得越來越重要。 IIRC中，.NET 4.5對GC暫停有更多的緩解（這可能會導致UI陷阱），但對於託管代碼，它們仍然是現實。因爲.NET和C++使用相同的WinRT框架，所以在與XAML/WinRT平臺進行交互時可能不會有太多差異（技術上通過C++與WinRT對象進行更快的交互，但命中率非常小），但當然你的用戶代碼通常比C++更快。

即使與混淆的.NET代碼相比，C++通常更難以進行反向工程。儘管狡猾的小偷可以竊取你的IP。因爲爲了方便開發人員和開發人員的工作效率創建了.NET，所以在構建應用程序時（例如，基於反射的工具，如DI/IoC），您將有更多便利選擇。

通過.NET迭代應用程序代碼可能會更容易，因爲.NET編譯速度比C++快，但正確創建的C++項目可以大大減輕。

純.NET項目可以支持「任何CPU」，這意味着您的應用程序可以在所有支持的WinRT平臺上運行。 C++項目，您將只需重新編譯以支持ARM，x86/64。如果.NET應用程序依賴於定製的C++組件，則必須針對每種體系結構進行編譯。因爲WinRT是從頭開始創建以支持多種語言，所以我建議開發不適合使用C++的建議是堅持使用.NET，但要探索從C++中受益的領域。微軟在/ CX預測方面做得很好，大多數C＃開發人員應該能夠找到解決方法。我對C++開發者的建議是堅持使用C++並獲得C++的所有好處。

Answer 2

從XAML角度看，它成爲一種語言選擇。無論您在此選擇哪種代碼語言，XAML UI堆棧都是相同的。根據您的應用程序目標，如果您需要該語言爲您提供的好處，那麼使用C++可能更有意義。

我們現在還可以在Win8中混合使用DirectX和XAML，這通常意味着C++ - 但是像SharpDX這樣的項目仍然不完全有效（是的，我意識到您將支付DirectX中的性能，包裝在託管代碼中...我只是指出它可以完成）。

你的問題似乎是關於創建一個可在桌面和Metro中使用的可重用組件。這可能有點具有挑戰性，這取決於您如何構建它，因爲需要對文件位置與嵌入資源之間的資源（即generic.xaml）加載方式進行一些更改。

Answer 3

我認爲使用C++/XAML的唯一好處是如果速度對您的項目很重要。 C＃/ XAML的優點是編碼更容易，特別是如果您的項目已經在C＃中了。

到現在也沒有辦法使同時指定地鐵站和在Windows 8

希望桌面這有助於應用程序。

Answer 4

那麼其他人可能知道更多，但基於Microsoft's answer to a question I posed back around WinRT announcement time：

的WinRT是一個協議和一組本地API，允許每個語言忠於其現有的執行環境 - 查克拉爲JavaScript，CLR爲C＃和用於C++的CRT /原始本機代碼。

這表明類似的性能權衡什麼，我們使用CLR與本地代碼訪問本質上是本機代碼API（WinRT的）當前體驗。但我期待看到這方面的一些經驗性調查，以瞭解WinRT的不同之處。