std::filesystem::path未提供反向迭代器的技术原因是什么？

首先明确：不存在技术实现障碍 #

std::filesystem::path的迭代器本身属于双向迭代器，完全支持反向遍历的能力，实现rbegin()/rend()成员函数没有任何技术难点，成本确实如你所说几乎为零。

未提供的核心原因：接口设计裁剪 #

该设计属于标准委员会的主动决策，而非能力限制：

• std::filesystem::path的核心定位是路径语义的抽象，而非路径组件的存储容器，因此只保留了最基础的正向遍历接口，没有刻意对齐常规容器的全套接口
• 类似未提供的接口还有直接返回组件总数的size()成员，这类衍生功能都被认为可以通过标准库算法配合基础迭代器实现，没必要额外增加接口复杂度
• 该设计也延续了boost.filesystem的原有设计，标准制定阶段没有将反向迭代器成员纳入新增需求

反向遍历的现成解决方案 #

你不需要手动编写循环，直接用标准库的std::reverse_iterator适配器即可实现和原生反向迭代器完全一致的效果，比如查找最后一个匹配"b"的组件：

#include <filesystem>
#include <algorithm>
#include <iterator>

namespace fs = std::filesystem;

int main() {
    fs::path p = "/a/b/c/b/d/b/e";
    auto last_b = std::find(
        std::make_reverse_iterator(p.end()),
        std::make_reverse_iterator(p.begin()),
        fs::path("b")
    );
    // 若找到，last_b.base()就是对应正向迭代器的位置
    return 0;
}

内容的提问来源于stack exchange，提问作者Adrian McCarthy