在Windows8中，编写C#/XAML与C++/XAML WinRT应用程序有哪些优缺点？

Question

我希望能够将一个 WPF/Silverlight 组件移植到 Windows 8。为了更好地理解，这个组件是一个 实时 WPF 图表，使用了 WPF/XAML 和位图渲染的混合方式来实现高性能。

我希望这个组件能够与 Metro 兼容，例如在 Metro 模式和桌面模式下都可以使用。我阅读了很多关于在 Windows 8 中创建 C++/WinRT 应用程序以及 C#/XAML 应用程序的文章，但这两种框架之间有什么区别呢？

如果选择 C#/XAML 而不是 C++/XAML，是否存在限制？此外，如果我能坚持使用 C#/XAML，从 .NET4.0 移植到 Windows8 会更加容易，但我能否使用这种方法创建一个完整功能的 Metro 组件呢？

期待您的评论或建议。

编辑：

如果您要投票关闭此线程，请发表评论说明原因。这是一个有效的问题，有+6票、四个答案和一个收藏。在我看来，保留它是合理的！

- Dr. Andrew Burnett-Thompson

---

如果速度很重要，使用C++/XAML；如果不是，使用C#/XAML会更容易，就像你说的那样。 - Adrian

但是在C++中真的会更快吗？这是关于速度的C#与C++之间的老论点。您可以通过更好的编码来减轻许多C#的缺点。我需要知道的是，C#和C++的功能集是否不同。例如，我能否使用C#/Xaml创建一个完整的组件以针对Metro和桌面模式？谢谢！ - Dr. Andrew Burnett-Thompson

在C++中速度总是更快的，但你不能创建一个可以在Metro和桌面上运行的项目。它必须是其中之一。 - Adrian

疯了。你能双重部署吗？就像你如何为Silverlight和WPF编写代码并将代码“共享”为链接一样？顺便说一下，如果你把你知道的东西写成答案，我会很高兴投票支持 :) - Dr. Andrew Burnett-Thompson

@Kobe：错了，错了，还是错了。对于组件编写者来说，选择C++和C#有不同的答案。选择C++更为有利，因为它不会带入额外的依赖项。客户端可能不使用您的组件，因为他们的C++代码不想加载CLR。接下来是性能问题。在堆管理方面，C#比C++表现更好，速度相差很大。如果您的应用程序创建许多短暂的小对象，您将看到C#代码运行速度快上一个数量级。此外，WinRT组件可以在Windows Store应用程序以及桌面应用程序中使用。 - IInspectable

Answer 1

我认为这种区别更多是一种设计选择，而不是个人对语言的偏好。偏好可能更与VB和C#相关。通常，在选择C++或.NET时会得到相同的差异。

C++会给您更快的启动时间。如果我没记错的话，.NET 4.5具有自动NGEN功能（不确定它如何与Metro应用程序相关），因此这可能有助于减轻.NET应用程序的典型缓慢启动时间。

C++将使您的内存使用更低，因为它不使用垃圾收集器。这在资源受限设备上（例如平板电脑）变得越来越重要。如果我没记错的话，.NET 4.5具有更多GC暂停的缓解措施（可能导致UI卡顿），但它们仍然是托管代码的现实。

由于.NET和C++使用相同的WinRT框架，因此在与XAML/WinRT平台交互方面可能不会有太大的区别（通过C++与WinRT对象交互技术上更快，但差距非常小），但当然，使用C++时您的用户代码通常比.NET更快。

相对于混淆的.NET代码，C++通常更难逆向工程。虽然狡猾的小偷仍然可能窃取您的知识产权。

由于.NET最初是为了开发人员和开发人员生产力而创建的，因此您将在构建应用程序时有更多的便利选项（例如，基于反射的工具，如DI/IoC）。

通过.NET迭代应用程序代码可能会更容易，因为.NET编译速度比C++快，但是正确创建的C++项目可以大大缓解这一点。

纯.NET项目可以支持" Any CPU"，这意味着您的应用程序可以在所有支持的WinRT平台上运行。 C++项目则必须重新编译以支持ARM、x86/64。如果您的.NET应用程序依赖于自定义C++组件，则必须为每个体系结构进行编译。

因为WinRT从一开始就支持多种语言，所以我建议那些不熟悉C ++的开发人员坚持使用.NET，但要探索受益于C ++的领域。微软在/CX投影方面做得很好，大多数C#开发人员应该能够找到自己的路。对于C++开发人员，我的建议是坚持使用C++并获得所有C++的优势。

- Jeremiah Morrill

---

哇，感谢这份比较/总结。我能问一个问题吗？如果我编写一个 C#/Xaml 用户控件，它可以在 C++/WinRT 应用程序中使用还是只能用于 C# 应用程序？ - Dr. Andrew Burnett-Thompson

你可以在C++应用程序中使用C# WinRT组件。尽管开发人员应该知道他们会带上整个CLR依赖项...因此，一些纯C++应用程序可能会避免使用它。 - Jeremiah Morrill

明白了。对于Win8的首次亮相，将现有组件直接移植到C#似乎是最好的选择。然而，对于更专业的应用程序，使用C++开发可能会更值得一试。 - Dr. Andrew Burnett-Thompson

Answer 2

从XAML的角度来看，这变成了一种语言选择。无论您选择哪种代码语言，XAML UI堆栈都是相同的。根据您的应用目标，如果需要使用该语言提供的优势，则使用C++可能更有意义。

现在我们也可以在Win8中混合使用DirectX和XAML，通常意味着使用C++，但是对于像SharpDX这样的项目来说，这仍然不完全有效（是的，我意识到您将为包装托管代码而支付DirectX性能损失...我只是指出它是可以做到的）。

您的问题似乎是关于创建可重用组件，可在桌面和Metro上使用。这可能有些具有挑战性，取决于您如何架构它，因为某些更改需要从文件位置加载资源（即generic.xaml），而不是嵌入式资源。

- Tim Heuer

---

我实际上阅读了有关C#/Xaml和SharDX的文章：http://advertboy.wordpress.com/2012/04/04/directx-in-your-winrt-xamlc-apps-sharpdx/ 真的非常好。我确实希望速度快，但也希望易于移植。这是一个现有的C#/WPF组件，共享代码库会让我非常高兴 :-) - Dr. Andrew Burnett-Thompson

+1 当@TimHeuer说“We also have…”时，您可以在响应中看到微软的风格 :) - K Mehta

Answer 3

我能想到使用C++/XAML的唯一优势是如果速度对你的项目很重要。

C#/XAML的优点是编码更加容易，特别是如果你的项目已经在C#中了。

目前还没有办法制作一个同时面向Windows 8的Metro和桌面应用程序。

希望这可以帮到你。

- Adrian

---

我猜WinRT C++组件可以在C++/WinRT或.NET中使用，而.NET组件只能在.NET中使用。这样说对吗？ - Dr. Andrew Burnett-Thompson

我认为这会让你更好地理解 :) http://en.wikipedia.org/wiki/Windows_Runtime - Adrian

使用C++（无论是纯C++还是C++/CX）有许多优点，而性能可能是最不重要的一个。随着.NET Native的出现，启动时间已经达到了可比较的数字。然而，更重要的是（至少对我来说）：确定性垃圾回收。在C++中，您可以看到对象何时被处理以及析构函数何时运行。在.NET中，您经常需要猜测，如果一个对象包装了本地共享资源，事情很容易就会出错。甚至更重要的是：C++组件可以在任何应用程序中使用，而不必拖入CLR依赖项。 - IInspectable

Answer 4

根据我在WinRT宣布时提出的问题，微软给出了以下答案：WinRT是一种协议和一组本地API，允许每种语言保持其现有的执行环境 - JavaScript使用Chakra，C＃使用CLR，C ++使用CRT /原生代码。这表明与我们当前使用CLR与本机代码访问本质上是本机代码API（WinRT）时经历的类似性能权衡。但我期待看到一些实证研究，以了解WinRT有何不同。

- ZeroBugBounce