c++ - native C++ 库与 UWP 互操作的建议/经验

Question

首先:我知道包含“建议”的问题标题会尖叫反对票和“非建设性”标记，但如果您先阅读此内容并考虑到我面临的问题，我会很高兴可访问学习 Material /文档方面的具体问题。

ATM 我正在​​尝试将我现有的应用程序从 Linux 扩展到 Windows。结构基本上由一个包含几个静态 native C++ 库的后端核心组成，我从一个前端项目(C/C++ GTK 和其他语言)中调用它们。恕我直言，通过使用核心 C++ 库并将它们插入不同平台特定的前端，将此类项目扩展到其他平台应该是一个非常普遍的计划。在这种情况下，这将是一个 UWP 项目。

让我感到困惑的是 Microsoft 与 C# 的互操作策略看似不一致、现在正在过渡的格局，特别是 C++/CX 和 C++/WinRT。 我正在努力解决的核心问题是:在您的系统中实现 native C++ 库(也通过将它们作为项目嵌入 Visual Studio 以在 Windows 上提供 native 构建体验和依赖项管理)的最佳方法是什么？ UWP应用程序？ C++/WinRT 似乎非常关注 WinRT 消耗(这是有道理的，因为它应该是这样的!)。 C++/CX 似乎已被正式放弃和弃用，当您在 VS 中选择一个 Visual C++ 库项目时，它会自动引用 VC++ 库，这些库不是 native 的，我担心某种中间层会妨碍您。

对于这种情况一定有某种工业最佳实践，不是吗？

Answer 1

C++/WinRT 和较旧的 C++/CX 语言扩展只是使 Windows 运行时接口(interface)更易于从 C++ 工作的方法。 Windows 运行时的关键设计值(value)之一是可以更轻松地编写可投影到 C++、C# 和 JavaScript 的组件。

如果您的组件的目的是供所有这些语言使用(这会严重影响界面设计)，那么为您的代码创建 Windows 运行时界面就很有值(value)。您的组件/库的客户端可以自由使用他们想要使用您的 Windows 运行时类型的任何方法:C++/WinRT、C++/CX、C# 或 JavaScript 互操作。

至于内部实现，则由您决定。 C++/WinRT 支持创作 Windows 运行时组件，如果您正在寻找“现代 C++”方式来编写 Windows 运行时 API，那么如果您是从头开始，这是一个不错的选择。您也可以使用 C++/CX 或 Windows 运行时库 (WRL)，尽管 WRL 需要一些努力来保持 MDL 生成同步。

Author APIs with C++/WinRT

Walkthrough: Creating a Windows Runtime component in C++/CX, and calling it from JavaScript or C#

The Windows Runtime Library (WRL) (Channel 9)

另一方面，如果您只是编写一个希望由 C++ UWP 应用程序使用的 C++ 库，只需创建一个 C++ UWP 或经典 Win32 桌面应用程序可以使用的标准 C++ 库(我在例如DirectX Tool Kit)。这对您的库提出的唯一要求是坚持 UWP 应用程序可用的 Win32 API 表面区域。参见 this blog series出于各种考虑。通常，您可以将其归结为现有代码的配置风格。

如果您想同时支持 native C++ 接口(interface)和 Windows 运行时 API 以供 C#/JavaScript 使用，您可以提供一个带有 native Windows 运行时 API 的可选组件(如 Win2D 对 Direct2D/DirectWrite/WIC 所做的那样)。

A little historical aside: WRL was the first solution for using Windows Runtime APIs from C++ but it was felt it was too difficult to use to author WinRT interfaces. Microsoft internal developers still used WRL for component development, but general developers were recommended to use the C++/CX path. See Inside the C++/CX Design. C++/CX heavily borrowed from existing 'reserved words' from Managed C++, which was less likely to conflict with existing code but also really confused people familiar with Managed C++.

C++/WinRT is a more modern solution that results in much more intuitive native C++ language projections of Windows Runtime types. The technology relies heavily on C++14/++17 language features which have been in development for some time, so it's really only been possible to fully implement the C++/WinRT solution recently. Consuming Windows Runtime async APIs in an intuitive native C++ way requires using co-routines which are in the C++20 draft. So overall, C++/WinRT is an elegant solution but requires cutting-edge compiler technology. See C++/WinRT