在Windows8中编写C#/XAML与C++/XAML WinRT应用程序的优缺点是什么
本文关键字：XAML 应用程序 WinRT 优缺点 是什么 C++ Windows8 | 更新日期: 2023-09-27 18:30:03
我想把WPF/Silverlight组件移植到Windows8。就上下文而言，该组件是一个实时WPF图表，它混合使用WPF/XAML和位图渲染来实现高性能。
我希望该组件与Metro兼容，例如用于Metro模式和桌面模式。我读了很多关于在Windows8中创建C++/WinRT应用程序以及C#/XAML应用程序的文章，但这两个框架之间有什么区别？
如果选择C#/XAML而不是C++/XAML，会有限制吗？还要考虑一下，如果我能坚持使用C#/Xaml，从.NET4.0中的C#/Xaml移植到Windows8会容易得多，但是我能用这种方法创建一个功能齐全的Metro组件吗？
感谢您的意见/建议。
编辑：
如果你要投票关闭这个帖子，请发表评论为什么。这是一个有效的问题，有+6票，四个答案和一个最喜欢的。对我来说，保留它似乎很合理！
我认为这是一种设计选择，而不是个人对语言的偏好。首选项将更多地与VB和C#相关。一般来说，这与您在任何选择C++或.NET.的应用程序中获得的差异相同
C++将为您提供更快的启动时间。IIRC，.NET 4.5具有自动NGENing功能（不确定它与城域应用程序的关系），因此这可能有助于缓解.NET应用程序典型的缓慢启动时间。
C++不会使用垃圾收集器，因此可以降低一般内存使用率。这在平板电脑等资源受限的设备上变得越来越重要。IIRC，.NET 4.5对GC暂停有更多的缓解措施（这可能会导致UI停滞），托管代码仍然是现实。
由于.NET和C++使用相同的WinRT框架，因此在与XAML/WinRT平台交互方面可能不会有太大差异（从技术上讲，通过C++与WinRT对象交互更快，但命中率非常小），但当然，使用C++的用户代码通常会比使用.NET.更快
C++通常更难进行反向工程，即使与模糊的.NET代码相比也是如此。尽管狡猾的小偷无论如何都可以偷走你的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++的所有好处。
从XAML的角度来看，它成为一种语言选择。无论您在此处选择哪种代码语言，XAML UI堆栈都是相同的。根据你的应用目标，如果你需要C++语言为你提供的好处，那么使用C++可能更有意义。
我们现在也可以在Win8中混合DirectX和XAML，这通常意味着C++——然而，对于像SharpDX这样的项目，它仍然不是完全有效的（是的，我意识到你会因为封装托管代码而在DirectX中付出性能上的代价……我只是指出这是可以做到的）。
您的问题似乎是关于创建一个可在桌面和Metro上使用的可重用组件。这可能有点挑战性，这取决于您如何构建它，因为需要对从文件位置加载资源（即generic.xaml）的方式与嵌入资源的方式进行一些更改。
我能想到的使用C++/XAML的唯一优势是速度对您的项目很重要。C#/XAML的优点是更容易编码，尤其是如果您的项目已经在C#中了。
到目前为止，还没有办法在Windows8中制作一个同时针对Metro和桌面的应用程序。
希望这能有所帮助。
其他人可能知道更多，但根据微软对我在WinRT发布时间提出的一个问题的回答：
WinRT是一个协议和一组原生API，允许每种语言保持其现有执行环境的真实性-JavaScript的Chakra、C#的CLR和C++的CRT/raw原生代码。
表明与我们目前使用CLR与本机代码访问本质上是本机代码API（WinRT）的情况类似的性能权衡。但我期待着看到一些对此的实证调查，看看WinRT有多不同。