我正在制作一个名为“C++ 游戏开发”的学生项目。这是一个有客户端和服务器的纸牌游戏。客户端应用程序包含一些我已经在 Visual Studio 2013 中使用 Windows 窗体制作的窗口。对于客户端/服务器通信，我决定使用Internet Communications Engine (ICE)。在构建客户项目期间，ICE 自动生成的代码出现错误。我发现 ICE 不支持 C++/CLI，只支持原生 C++ 或 C#（我不能使用）。
所以现在我正处于一个十字路口，无论是使用本机 C++ 制作整个客户端应用程序（这意味着例如使用我不熟悉的 MFC）还是同时使用本机 C++ 和 C++/CLI（把我已经完成的工作使用 Windows 窗体到 CLR 类库并从带有入口点的本机 C++ 项目链接到它），这也不是微不足道的。
我正在尝试选择耗时较少的选项。我要求帮助我估计这些方法的复杂性。我更喜欢第二个，但我不确定它是最简单的。
这取决于您的 GUI 中已经存在多少复杂性。如果您有一百个对话框/控件，那么用本机 C++ 重写它可能是错误的答案。在这种情况下，将您的 GUI 变成一个库更有意义。
但是，将您的 GUI 保留为一个进程并在本机 C++ 中构建一个代理库，将 ICE 调用传递到您的服务器上，这可能是一个更好的选择。（因此 C++/CLI exe 调用新 C++ 库中的一个函数，该函数对服务器进行 ICE 调用，反之亦然）。
如果您的 GUI 很小，那么在现代（并且更好地支持 C++/CLI）系统中重写它是最好的选择。Qt 可能是当今原生 GUI 的终极版（但也有诸如 MFC 或 wxWidgets 之类的替代品）。即使在这些情况下，将您的网络子系统编码为本机库仍然可能更好。然后，您可以更改您的 GUI 并根据需要尝试大量 GUI 堆栈，只需更改 1 个表示层即可将您的游戏移植到 Android 或 iOS。
第三种选择是选择不同的通信系统。虽然像 ICE 这样的 RPC 很不错，但今天的“位置”是通过 REST 服务的基于 Web 的通信（尝试像 Mongoose 或 NxWeb 这样的嵌入式 c++ Web 服务器），如果您需要将数据推送回客户端，这些支持 WebSockets，所以将提供您需要的所有功能。然后，您可以将您的 GUI 重写为基于 HTML！
所以：把你的通讯放在一个原生的 C++ 库中。
C++/CLI 可以很好地使用本机 C++ 代码。
将生成的代码粘贴到没有/clr. 然后将该静态库列为 C++/CLI DLL 的依赖项。
链接器将找出其余部分。结果称为“混合模式装配”。
请注意，您的通讯库可能不接受托管类型。没关系，C++/CLI 可以完美地混合非托管数据模型和托管视图 (UI) 类。