在 Windows8 中编写 C#/XAML 与 C++/XAML WinRT 应用程序的优缺点是啥？ [关闭]

Posted 2023-02-25

【中文标题】在 Windows8 中编写 C#/XAML 与 C++/XAML WinRT 应用程序的优缺点是啥？ [关闭]

【英文标题】：What are the pros and cons of writing C#/XAML vs. C++/XAML WinRT applications in Windows8? [closed]在 Windows8 中编写 C#/XAML 与 C++/XAML WinRT 应用程序的优缺点是什么？ [关闭]

【发布时间】：2012-04-19 09:20:46

【问题描述】：

我想沿着将 WPF/Silverlight 组件移植到 Windows 8 的路线。对于一些上下文，该组件是 real-time WPF Chart，它使用 WPF/XAML 和位图渲染的混合来实现高性能。

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

如果您选择 C#/XAML 而不是 C++/XAML，是否有限制？还要考虑从 .NET4.0 中的 C#/Xaml 移植到 Windows8 会容易得多，如果我可以坚持使用 C#/XAML，但是我能否使用这种方法创建一个功能齐全的 Metro 组件？

感谢您的 cmets/建议。

编辑：

如果您投票关闭此线程，请发表评论原因。它是一个有效的问题，有 +6 票，四个答案和一个最爱。把它留给我似乎是合理的！

【问题讨论】：

如果速度很重要，请使用 C++/XAML，如果不使用 C#/XAML，如您所说，对您来说会更容易

但是在 C++ 中真的会更快吗？旧的论点 C# 与 C++ 的速度。您可以通过更好的编码来缓解许多 C# 的缺陷。我需要知道的是，C# 与 C++ 的功能集是否不同。例如。我可以在 C#/Xaml 中创建一个功能齐全的组件以同时针对 Metro 和桌面模式吗？谢谢！

在 C++ 中总是更快，但您不能创建同时在 Metro 和桌面上运行的项目。它必须是一个或另一个

疯了。那么你可以双重部署吗？就像您如何为 Silverlight 和 WPF 编写代码并将代码“共享”为链接一样？顺便说一句，如果你写出你所知道的答案，我很乐意投票:)

@Kobe：错了，错了，错了。组件编写器的 C++ 与 C# 有不同的答案。使用 C++ 是有利的，因为它不会拖入额外的依赖项。客户可能不会使用您的组件，因为他们的 C++ 代码不想加载 CLR。接下来：性能。在堆管理方面，C# 以显着优势击败 C++。如果您的应用程序创建了许多短暂的小对象，您将看到 C# 代码的运行速度提高了一个数量级。此外，WinRT 组件可用于 Windows 应用商店应用程序以及桌面应用程序。

【参考方案1】：

我将差异视为设计选择，而不是个人语言偏好。偏好与 VB 与 C# 更相关。通常，在您选择 C++ 或 .NET 的任何应用程序中，您会得到相同的差异。

C++ 将为您提供更快的启动时间。 IIRC，.NET 4.5 具有自动 NGENing 功能（不确定它与 Metro 应用程序的关系如何），因此这可能有助于缓解 .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++ 的领域。 Microsoft 在 /CX 预测方面做得很好，大多数 C# 开发人员应该能够找到自己的方法。我对 C++ 开发人员的建议是坚持使用 C++ 并获得 C++ 的所有好处。

【讨论】：

哇，感谢您的比较/破败。我能问个问题吗？如果我创作了 C#/Xaml 用户控件，它可以在 C++/WinRT 应用程序中使用还是仅在 C# 应用程序中使用？

您可以在 C++ 应用程序中使用 C# WinRT 组件。尽管开发人员应该意识到他们带来了整个 CLR 依赖项......所以一些纯 C++ 应用程序可能会回避使用它。

知道了。对于 Win8 首次亮相来说，将现有组件直接移植到 C# 听起来是最好的选择。然而，对于更专业的应用程序，它可能值得用 C++ 开发

【参考方案2】：

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

我们现在还能够在 Win8 中混合 DirectX 和 XAML，这通常意味着 C++——但是对于像 SharpDX 这样的项目仍然不完全有效（是的，我知道你会在 DirectX 中为包装付出性能损失在托管代码中...我只是指出它可以做到）。

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

【讨论】：

我实际上读过那篇关于 C#/Xaml 和 SharDX 的文章：advertboy.wordpress.com/2012/04/04/… 确实非常好。我确实想要速度，但也想要轻松的端口。这是 C#/WPF 中的现有组件，共享代码库会让我很高兴 :-)

+1 当@TimHeuer 说“我们也有...”时，您可以在响应中看到微软的风格:)

【参考方案3】：

我能想到的使用 C++/XAML 的唯一优势是速度是否对您的项目很重要。 C#/XAML 的优点是更容易编码，特别是如果您的项目已经使用 C#。

到目前为止，还没有办法在 Windows 8 中制作同时针对 Metro 和桌面的应用程序。

希望这会有所帮助。

【讨论】：

我猜 WinRT C++ 组件可以在 C++/WinRT 或 .NET 中使用，而 .NET 组件只能在 .NET 中使用。听起来对吗？

我想这会让你更好地理解:) en.wikipedia.org/wiki/Windows_Runtime

使用 C++（无论是普通的，还是 C++/CX）有很多优点，而性能可能是最不重要的一个。随着 .NET Native 的推出，启动时间已达到可比数字。不过，更重要的是（无论如何对我而言）：确定性 垃圾回收。在 C++ 中，您可以看到对象的处置位置以及析构函数的运行位置。在 .NET 中，您经常不得不猜测，如果一个对象包装了一个本地共享资源，那么事情很容易被破坏。也许更重要的是：C++ 组件可以在任何应用程序中使用，而无需拖入 CLR 依赖项。

【参考方案4】：

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

WinRT 是一种协议和一组原生 API，允许每种语言保持其现有执行环境的真实性 - 用于 javascript 的 Chakra、用于 C# 的 CLR 和用于 C++ 的 CRT/原始本机代码。

这建议与我们目前使用 CLR 与本机代码访问本质上是本机代码 API (WinRT) 的体验类似的性能权衡。但我期待看到对此进行一些实证调查，以了解 WinRT 有何不同。