为什么 C++ 20 范围算法在<algorithm>和意见<ranges> ?

Question

我承认这是对命名的挑剔，但除了我对命名的挑剔之外，我还有一些现实生活中的代码审查经验，我看到人们在只需要<algorithm>时包含了<ranges> ，例如在使用std::ranges::count_if .

那么为什么将范围算法放在<algorithm>而将视图放在<ranges> ？ 对我来说更有意义的是：

• 将范围算法放入<algorithm>并将<ranges>重命名为<views> / <range_views>
• 将范围算法和视图都放在<ranges>

注意：我知道我过于简化了标题之间的区别， <ranges>还包含很多概念和构建块，因此这可能是理由的一部分。

Answer 1

我不是提案的作者，所以我无法规范地回答做出这个选择的原因。 充其量，我可以提出选择有意义的原因。

One Ranges 提案 P0896R4 似乎没有选择的理由。 Range Adapters and Utilities P0789R3 没有这些算法。

那么为什么要把范围算法放在<algorithm>

线索在名称中 :) 它们是算法，可以在此标题中找到算法。

如果有人正在寻找find_if ，他们可以在同一个地方找到迭代器算法和范围算法。

那么为什么要把 range [...] 视图放在<ranges>呢？

过去在任何现有标题中都没有视图，因此使用现有标题可能并不合适。 因此引入了一个新的标题。

有一个类似的视图子集，即范围适配器视图。 曾经（现在仍然是）迭代器适配器。 这些在<iterator>中定义。 我认为那不是放置范围适配器的好地方。

将范围算法放入<algorithm>并重命名为<views> / <range_views>

但是<ranges>不仅仅包含视图。 它包含的概念，如ranges::range ，范围原始类，如ranges::sentinel_t ，特定范围内的迭代器，如ranges::borrowed_iterator_t ，即类似于迭代设施诸如函数std::ranges::begin 。 命名标题<views>可能会产生误导。

将范围算法和视图都放在<ranges>

也许如果迭代器算法最初被放置在<iterator> ，那么范围算法将被放置在<ranges>以遵循该约定。 但实际上，之前的约定是将算法拆分为单独的标题，并且遵循该约定的是范围。