c++ - 如何通过源代码中的执行策略检测C++ 17扩展内存管理算法的可用性？

Question

P0040R3(adopted 2016-06，另请参见N4603)在草案中引入了一些扩展的内存管理算法，例如std::uninitialized_move_n，最终成为ISO C++ 17的一部分。其中一些具有ExecutionPolicy参数的额外重载，以潜在地支持并行性。

但是，截至目前(2018年8月)，我还没有找到这些重载实现附带的任何标准库实现。我检查过的实现文档并没有很好地阐明它。具体来说，(当前)它们是:

libstdc++显示它不支持中继中的P0040R3，但实际上至少在GCC 8.2中，std::destroy_at和不含std::uninitialized_move_n的ExecutionPolicy。

从4.0开始，

libc++对P0040R3具有“完全”支持，但是ExecutionPolicy的重载实际上是缺失的。

自VS 2017 15.3起，

Microsoft VC++支持带有/std:c++17或/std:c++latest的P0040R3，但实际上缺少ExecutionPolicy的重载。

我知道的唯一带有ExecutionPolicy重载的实现是在HPX中，但这不是标准库的完整实现。如果要便携式使用这些功能，则必须同样适应自定义实现，而不是直接使用std名称。但是我仍然希望将来使用std实现作为首选项(除非它们有已知的错误)。 (原因是，实现定义的执行策略与具体的实现紧密结合，因此，外部实现及其客户代码一般来说，利用各种执行策略的机会会更少；尽管对于客户代码而言，这不一定是正确的。因此，我希望可以在我的适用的适应性自适应层中有条件地包含一些内容，以用于实现-在标准库提供它们时用using std::...获得指定的功能，并用我的功能对其进行补充仅在必要时才将实现作为标准库实现中缺少的部分的后备。

如我所知，SD-6 feature testing macros和P0941R2显示__cpp_lib_raw_memory_algorithms足以满足P0040R3中的功能。另一方面，__cpp_lib_parallel_algorithm似乎与<memory>根本无关。因此，无法像当前的libc++和MSVC实现那样表达状态-使用P0040R3中的std名称，但缺少ExecutionPolicy重载。而且我不确定__has_include<execution>是否能正常工作。现实可能更怪异，例如P0336R1甚至是not supported by libc++。

因此，当功能(希望)在某些较新版本的标准库实现中可用时，如何使这些功能完美地移植到我的代码中，而不是检查每个版本的源代码，或者彻底重塑整个P0040R3的外观？

编辑:

我知道功能测试宏的预期用途，并且我认为libstdc++做对了。但是，仍有改进的空间。更具体地说，我的可移植层代码将扮演实现的角色(如HPX)，但在标准库实现已提供轮子的情况下，它们的意义就更轻巧，而不是重新发明轮子:

namespace my
{
#if ???
//#if __cpp_lib_raw_memory_algorithms
using std::uninitialized_move_n;
// XXX: Is this sufficient???
#else
// ... wheels here ... not expected to be more efficient to std counterparts in general
#endif
}

所以我的客户代码可以是:

my::uninitialized_move_n(???::par, iter, size, d_iter);

而不是(摘自Barry的回答):

#if __cpp_lib_raw_memory_algorithms
std::uninitialized_move_n(std::execution::par, iter, size, d_iter);
#else
// ???
#endif

这两段代码都可以工作，但是显然直接在客户端代码中的任何地方检查__cpp_lib_raw_memory_algorithms的成本更高。

理想情况下，我应该拥有一些完整的最新标准库实现，但是并非总是可以保证的(特别是在将标准库作为系统库的一部分安装的环境中使用)。无论如何，我需要进行调整以减轻客户的工作负担。

回退很明显:完全避免using std::uninitialized_move_n;路径。恐怕这将是一个悲观的实现，因此我想在可能的情况下避免这种方法。

第二次更新:

由于“完全可移植”的听起来还不清楚，因此我在上面的编辑中举例说明了一些代码。尽管问题没有改变，但标题仍然涵盖，但在此我将使其更加具体。

我想在问题中使用的“完全可移植”的方式受到限制，因为在给定类似上面的代码的情况下，它填充了???中标记的任何部分，而不依赖于任何特定版本的语言实现(例如，像宏名称之类的东西都不依赖于实现应该用于此目的)。

有关代码示例不符合条件的信息，请参见here和here。 (好吧，这些版本是通过检查提交日志来找出的……肯定是不完美的，在某些情况下还是有漏洞的。)请注意，这与ExecutionPolicy的重载无关，因为在提到的标准库实现中缺少它们，而我的下一个 Action 取决于此问题的解决方案。 (但是std中名称的 future 应该很清楚。)

完美(足够)的解决方案可以是，例如，添加一个新的功能测试宏以使重载独立于__cpp_lib_raw_memory_algorithms，因此将来，当独立的new不能检测到重载时，我可以使用ExecutionPolicy添加我的重载实现功能测试宏，而无需再次弄乱#if的条件。但是我当然不能保证这种方式是可行的。这最终取决于委员会和供应商的决定。

我不确定是否可以有其他指示。

Answer 1

P0941的初始版本包含一个表格，该表格清楚地表明P0040R3具有相应的功能测试宏__cpp_lib_raw_memory_algorithms。这意味着编写代码以有条件地使用此功能的正确，可移植的方式是:

#if __cpp_lib_raw_memory_algorithms
std::uninitialized_move_n(std::execution::par, iter, size, d_iter);
#else
// ???
#endif

所强加的要求是，如果定义了该宏，则该功能将存在并执行标准所规定的功能。但是，没有定义的宏实际上并没有说什么。如您所指出的那样，P0040R3的某些部分是在libstdc++中实现的-部分但不是全部，这就是为什么未定义功能测试宏的原因。

当前，人们正在齐心协力在libstdc++中实现并行算法。

至于在#else分支中该做什么，那么……您有点自己。