小编Fra*_*kHB的帖子

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

P0040R3(采用 2016-06,另见N4603)介绍了一些扩展内存管理算法,如std::uninitialized_move_n草案,最后它成为ISO C++ 17的一部分.其中一些有一个额外的过载,带有一个ExecutionPolicy参数,可能支持并行性.

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

libstdc ++表明它不支持主干中的P0040R3,但实际上至少std::destroy_at和std::uninitialized_move_n不支持ExecutionPolicyGCC 8.2.
自4.0以来,libc ++对P0040R3的"完全"支持,但ExecutionPolicy实际上缺少重载.
Microsoft VC++支持P0040R3,因为VS 2017 15.3带/std:c++17或/std:c++latest,但ExecutionPolicy实际上缺少重载.

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

众所周知,SD-6功能测试宏以及P0941R2显示__cpp_lib_raw_memory_algorithms对于P0040R3中的功能已足够.另一方面,__cpp_lib_parallel_algorithm似乎根本没有关系<memory>.所以没有办法像当前的libc ++和MSVC实现一样表达状态 - std名称来自P0040R3但没有ExecutionPolicy重载.而且我不确定__has_include<execution>会不会工作.现实可能更奇怪,例如,libc ++甚至不支持 P0336R1. …