loo*_*end 1 c++ c++-cx uwp c++-winrt
首先：我知道一个包含“建议”的问题标题会引起反对票和“非建设性”标志，但如果您先阅读本文并考虑到我在以下方面面临具体问题，我会很高兴可访问的学习材料/文档。
ATM 我正在尝试将我现有的应用程序从 Linux 扩展到 Windows。结构基本上由包含多个静态本机 C++ 库的后端核心组成，我从前端项目（带有其他语言的 C/C++ GTK）中调用这些库。恕我直言，通过使用 core-C++ 库并将它们插入到不同平台特定的前端，将此类项目扩展到其他平台应该是一个非常普遍的计划。现在，在这种情况下，这将是一个 UWP 项目。
让我感到困惑的是微软与 C# 互操作策略的看似不一致的、目前正在转换的景观，特别是 C++/CX 和 C++/WinRT。我正在努力解决的中心问题是：在 UWP 应用程序中实现本机 C++ 库（也将它们作为项目嵌入到 Visual Studio 中以在 Windows 上提供本机构建体验和依赖项管理）的最佳方法是什么？C++/WinRT 似乎非常关注 WinRT 消耗（这是有道理的，因为它应该是这样的！）。C++/CX 似乎已被正式放弃和弃用，当您在 VS 中选择 Visual C++ 库项目时，它会自动引用 VC++ 库，这些库不是本机的，我担心某种中间层会妨碍您。
对于这种情况，必须有某种工业最佳实践，不是吗？
C++/WinRT 和较旧的 C++/CX 语言扩展只是使 Windows 运行时界面更易于从 C++ 使用的方法。Windows 运行时的关键设计价值之一是使编写可投影到 C++、C# 和 JavaScript 的组件变得更加容易。
如果您的组件的用途是由所有这些语言（这会严重影响界面设计）使用，那么为您的代码创建 Windows 运行时界面就很有价值。您的组件/库的客户端可以自由使用他们想要使用您的 Windows 运行时类型的任何方法：C++/WinRT、C++/CX、C# 或 JavaScript 互操作。
至于内部实现，则取决于您。C++/WinRT 支持创作 Windows 运行时组件，如果您正在寻找“现代 C++”方式来编写 Windows 运行时 API，如果您是从头开始，这是一个很好的方法。您也可以使用 C++/CX 或 Windows 运行时库 (WRL)，尽管 WRL 需要一些努力来保持 MDL 生成同步。
演练：在 C++/CX 中创建 Windows 运行时组件，并从 JavaScript 或 C# 调用它
另一方面，如果您只是在编写希望由 C++ UWP 应用程序使用的 C++ 库，只需创建一个标准 C++ 库，C++ UWP 或经典的 Win32 桌面应用程序可以使用（我在例如DirectX Tool Kit 中这样做））。这对您的库提出的唯一要求是坚持在 UWP 应用程序可用的 Win32 API 表面区域内。请参阅此博客系列以了解此处的各种注意事项。通常，您可以将其归结为现有代码的配置风格。
如果要同时支持 C#/JavaScript 使用的本机 C++ 接口和 Windows 运行时 API，则可以提供带有本机 Windows 运行时 API 的可选组件（就像Win2D为 Direct2D/DirectWrite/WIC所做的那样）。
撇开一点历史不谈： WRL 是第一个从 C++ 使用 Windows 运行时 API 的解决方案，但人们认为使用它来编写 WinRT 接口太难了。微软内部开发者仍然使用 WRL 进行组件开发，但建议一般开发者使用 C++/CX 路径。请参阅C++/CX 设计内部。C ++ / CX巨资从现有的从托管C“保留字” ++，这是不太可能的冲突与现有的代码，但还借真糊涂熟悉托管C ++的人。
C++/WinRT 是一种更现代的解决方案，可生成更直观的 Windows 运行时类型的本机 C++ 语言投影。该技术在很大程度上依赖于 C++14/++17 语言特性，这些特性已经开发了一段时间，所以最近才真正有可能完全实现 C++/WinRT 解决方案。以直观的本机 C++ 方式使用 Windows 运行时异步 API 需要使用 C++20 草案中的协同例程。所以总的来说，C++/WinRT 是一个优雅的解决方案，但需要尖端的编译器技术。请参阅C++/WinRT