在 WPF/C# 和 Qt/C++ 之间进行选择 [关闭]

Question

我和我的团队正在开发一个应用程序，其中涉及一个用 C++ 编写的后端，并涉及到使用 OpenCV、MIL 等库。

现在，我们需要开发一个图形用户界面来与这个程序交互，图形用户界面显示图像，用户可以与图像交互并对图像进行注释/标记，然后运行用 C++ 编写的图像处理算法显示结果。

对于 GUI，我被困在 WPF 和 Qt 之间进行选择 我个人觉得 WPF 比 Qt 更简单、更强大 我知道 WPF 不能移植到 Linux，但我并不太担心这个...... 此外，WPF 使用 DirectX 技术，我可能不得不在稍后阶段使用它来生成一些 3-D 可视化。

请帮助我解决这些问题：

1. 我可以直接将 WPF 与 C++（而不是 Visual C# 吗？？）进行交互
2. 如果（第 1 点）是不可能的，那么考虑这个： C++ 中的代码会很大，而且还涉及一些库，所以我可以使用 C# 来调用 C++ 函数吗 花在学习 Qt 上的时间是否会比让我的非托管非 OO C++ 代码与 WPF 一起工作要少？

（我有一种下沉的感觉，我必须编写太多代码来将 C++ 与 WPF 接口，这可能等于重写了实际程序本身的一半...... :-()

Answer 1

我已经将 Qt 与 C++ 和 WPF 一起使用。我更喜欢 WPF 作为用户界面框架。 Qt 还不错，尤其是 4.0 之后。我什至不会碰早期版本的 Qt。

正如其他人在 cmets 中所说，WPF 的文档更好，在线社区更大。如果您正在查看样式化的应用程序 WPF 肯定是要走的路。 Qt 的声明式语言是新的，是沿着这条道路迈出的一个很好的步骤，但是因为它太新了，所以往往有点错误。 WPF 存在的时间更长，而且更成熟，功能也更丰富。

但是，我认为您的案例中真正的问题是您拥有的 c++ 代码库。

WPF 需要 C++/CLI 层（托管 C++）才能与您的 c++ 代码库正确交互。这听起来很复杂，并且确实需要一些工作，但它并不像听起来那么疯狂。还有大量关于此的文档。我个人会远离 PInvoke。

Qt 稍微简单一些，因为它是基于 c++ 的，但是您需要在 c++ 原生类型和内部使用的 Qt 类型（如 QString、QList 等）之间进行一些转换。

要考虑的另一件事是您希望 UI 的外观和感觉。例如，如果您正在考虑一个漂亮的 Ribbon (office 2008, 2010) 外观，那么您将无法使用 Qt 获得它。此外，还有大量的第三方 WPF 控件，但我还没有为 Qt 找到很多。在某些情况下，购买一套漂亮的控件来补充 Microsoft 默认提供的控件非常方便。

在过去的几年里，无论代码库如何，我们一直在使用 WPF。我们还没有后悔。

不过，我也会建议第三种选择。我相信 Code-jock 是一个基于 MFC 的 UI 框架。它基于 c++ 和 ActiveX。它已经变得相当复杂了。看看here。

编辑： 自从我第一次看到 QML 以来，它已经走了很长一段路。我没有时间深入研究它，但据我所知，它提供了一些非常有趣的功能。值得多看一看。

此外，正如一些 cmets 所指出的，还有更多类似于 Office 的控件，例如功能区，还有一些添加到 Qt 工具集中的图表和图形控件。这些确实使 Qt 成为一个有趣的前景。

不过，我会坚持我之前所说的，作为一名程序员，我发现使用 WPF 制作 UI 要容易得多，而且我对我的结果比我使用 Qt 编写的任何东西都更满意。

Answer 2

过去几年，我一直在使用 SWIG 使 WPF 应用程序中的纯（非托管）C++ DLL 可用。它工作得很好，完全没有问题，这适用于大型应用程序，例如航空电子设备维护培训师。

SWIG 很棒，因为使用一组接口文件（您基于 .h 头文件编写，非常简单），您可以生成所有脚手架代码以将 C++ DLL 导出为多种语言，例如 C#、Python ，Lua，Java。如果你想从 C# 或 Lua 扩展 C++ 类，SWIG 会生成你需要的代码，它处理跨语言传递异常（例如，Lua 脚本可能会抛出一个通过 C++ 层涓涓细流并在 C# 级别被捕获的异常) 等。我们永远不必接触 PInvoke（SWIG 完成所有操作）。太奇妙了。

这样，相同的 SWIG 接口允许我们将 WPF（C#，带有 .NET 4）用于 GUI，为我们必须集成的一些现有库使用本机 C++ 后端（通过 SWIG），并嵌入 Lua 解释器支持应用程序的脚本（通过 SWIG、相同的 .i 接口文件和 sourceforge 上的 lua-icxx 以简化与 Lua C API 解释器堆栈的接口）。

我想知道 Qt/QML 现在与 WPF/XAML 相比如何，在这个线程开始 2 年后。而且我看到现在有 Qt3D 来添加内置 3D，因为 WPF 中已经有一段时间了（本机支持 3D 画布，没有 OpenGL 或 DirectX）。

Answer 3

如果您已经拥有庞大的 C++ 代码库，我会说您应该坚持使用 Qt。 WPF 没有他们说的那么棒，也没有他们说的那么容易开发。 C++ 和 Qt 是著名的团队，普通的 C++（不是 .NET）和 WPF 不是。

Answer 4

在 WPF 场景中，您不会直接从 WPF（即 xaml 视图）直接连接到非托管 C++。您总是希望将 C++ 模块包装成某种 VB 或 C# 托管包装器。 （理论上，您可以使用托管 C++ 包装器，但这样做会很疯狂。） WPF 至少需要用 .NET 语言编写的精简视图模型。 WPF 不应该直接访问您的非托管代码，所以问题更多的是“.NET 应用程序可以与非托管 C++ 交互吗？”答案是肯定的。

http://msdn.microsoft.com/en-us/library/aa984739(v=VS.71).aspx

Answer 5

如果是 C++，请坚持使用 Qt。项目的 3D 部分可以由 Qt 的 OpenGL 小部件处理。 选择 WPF 路径将迫使您在 C# 或 VB.net 中执行某些部分（总是不好的做法）。 将 WPF 与 C++ 一起使用并没有太多优势。 此外，您的其余代码是 C/C++。适合您的需求。 OpenCV、MIL 等更容易与 Qt 集成，而不是使用 WPF 进行 P/Invoke 调用（由于 .Net 编组，这也会导致延迟）。

Answer 6

WPF 是 UI 框架，而不是编程语言。您可以使用 C# 或 VB .NET 编写 WPF 应用程序。要在 .NET 应用程序中使用本机 C++ 代码，您有两种选择：

1. PInvoke - 允许从本地库调用纯 C API。 PInvoke 不能与 C++ 类一起使用，只能与函数一起使用。它的工作方式与 VB6 中的 API 调用相同。

2. 使用 C++/CLI 包装器，您可以编写可供 C#/VB .NET 客户端使用的 .NET Dll。在内部，此 Dll 使用本机 C/C++ 库。

如果您对 WPF 感到满意，并且不需要跨平台解决方案，则可以使用它。您需要学习互操作性部分。 C++/CLI 是相当复杂的语言，但懂原生 C++ 和 .NET 的程序员都可以学。

另一方面，Qt 允许直接使用任何现有的 C/C++ 代码，并提供跨平台解决方案。

Answer 7

您的 WPF 代码需要使用 C# 或 VB 来获得设计器和工具支持。通过使用混合模式程序集，C# 和 C++ 之间的互操作非常好，它允许您在 C++ 中编写一个模块，该模块编译为托管和非托管代码的混合。这为您提供了与本机 C++ 库的类型安全互操作。

有关混合模式程序集的信息，请参阅here。我们可以为他们担保。

IMO 的一个重要考虑因素是 WPF 学习曲线。如果你能带上你的团队，我相信它会非常有成效。