Почему невозможно создать `std :: filesystem :: path` из итераторов` std :: filesystem :: path`?

Question

Почему невозможно создать `std :: filesystem :: path` из итераторов` std :: filesystem :: path`?

Следующий фрагмент кода предназначен для удаления первой части пути, если он существует:

#include <filesystem>

std::filesystem::path strip_prefix(std::filesystem::path p)
{
auto it{p.begin()};
if (it != p.end())
{
++it;
return std::filesystem::path(it, p.end());
}

return p;
}

(Увидеть: https://godbolt.org/z/wkXhcw)

Я был удивлен, узнав, что это не работает. Код не компилируется, так как конструктор пути принимает только итераторы, которые перебирают последовательности символов. Я могу видеть использование этого, но зачем ограничивать конструкцию только такими итераторами? На мой взгляд, нелогично не поддерживать построение пути из своих собственных итераторов. Насколько я знаю, большинство других типов STL поддерживают эту идиому.

Что может быть эффективной реализацией для достижения той же цели, кроме полной реконструкции нового пути?

ОбновитьВ этом контексте я нашел следующее обсуждение актуальным / забавным: http://boost.2283326.n4.nabble.com/boost-filesystem-path-frustration-td4641734.html. Я согласен с Дейвом здесь. Я думаю, что рассматривать путь как контейнер элементов пути — это очень естественный способ взглянуть на него.

10

c++c++17 std-filesystem

Решение

Другие решения

Других решений пока нет …

Источник

Accepted Answer

Самое простое решение для объединения сегментов, чтобы сделать новый path просто std::accumulate(),

Для вашего конкретного случая использования я бы сделал что-то вроде этого:

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{});
}

Что касается того, почему нет конструктора (или, возможно, свободной функции), чтобы сделать это? Я не знаю. Это похоже на необходимость, возникающую при работе с путями, но комитет, как правило, неохотно добавляет вспомогательные функции к стандартным классам, если тот же результат может быть достигнут с помощью вызова стандартного алгоритма.

3