C++ 为什么不能从`std:：filesystem:：path`迭代器构造`std:：filesystem:：path`？

以下代码旨在剥离路径的第一部分（如果存在）：

#包括
std:：filesystem:：path strip_前缀（std:：filesystem:：path p）
{      
if（auto-it{p.begin（）}；it！=p.end（））
{
++它；
返回std:：filesystem:：path（it，p.end（））；
}
返回p；
}

（见：）

我惊讶地发现这不起作用。由于路径构造函数只接受对字符序列进行迭代的迭代器，因此代码不会编译。我可以看到它的用途，但是为什么只将构造限制在这类迭代器上呢？在我看来，不支持从自己的迭代器构造路径是违反直觉的。据我所知，大多数其他STL类型都支持这种习惯用法

除了完全重建一条新的道路之外，实现同样目标的有效实施是什么

---

更新：在这种情况下，我发现以下讨论相关/有趣：。我同意戴夫的看法。我认为将路径视为路径元素的容器是看待它的一种非常自然的方式（从程序员的角度）。

连接段以创建新的

路径的最简单解决方案就是
std:：acculate（）

对于您的特定用例，我会这样做：

std::filesystem::path strip_prefix(std::filesystem::path p)
{
    if(p.empty()) return p;
    return std::accumulate(std::next(p.begin()), p.end(), 
                           std::filesystem::path{}, std::divides{});
}

至于为什么没有一个构造函数（或者一个自由函数）来做这件事呢？我不知道。在使用路径时，这似乎是一种需要，但是，如果通过调用标准算法可以获得相同的结果，委员会确实不愿意将方便函数添加到标准类中。
我不同意将这种类型的范围构造函数归类为多余的方便函数，因为实际上其他容器都是这样（除了
std:：valarray
和
std:：array
）有一个范围构造函数。@rubenvb哦，我并不是说它是多余的。我只是在理论上认为委员会可能会这样做。
path
的复杂之处在于它使用字符迭代器，但会产生段迭代器。我想不出另一个具有这种行为的
std
容器。我不相信
path
>从技术上讲，它是一个容器（你所说的可能与它有很大关系）。虽然它已经有字符迭代器范围构造函数，但可以说添加段迭代器构造函数并不难，这样就可以执行
path p{other_path.begin（），other_path.end（）-1}
或类似的把戏。@rubenvb，对于外部API，我认为将路径视为路径段的容器更为自然。我刚刚发现了相关的其他讨论：