Как делают я “нормализую” путь с помощью повышения:: файловая система?
Время компиляции в C ++
template<unsigned i>
struct factorial
{ static const unsigned value = i * factorial<i-1>::value; };
template<>
struct factorial<0>
{ static const unsigned value = 1; };
Использовать в коде как:
Factorial<5>::value
3 ответа
Boost v1.48 и выше
Вы можете использовать boost :: filesystem :: canonical :
path canonical(const path& p, const path& base = current_path());
path canonical(const path& p, system::error_code& ec);
path canonical(const path& p, const path& base, system::error_code& ec);
v1.48 и выше также предоставляют функцию boost :: filesystem :: read_symlink для разрешения символических ссылок. .
Версии Boost до v1.48
Как упоминалось в других ответах, вы не можете нормализовать, потому что boost :: filesystem не может следовать символическим ссылкам. Однако вы можете написать функцию, которая нормализует «насколько это возможно» (при условии, что «.» И «..» обрабатываются нормально), потому что boost предлагает возможность определить, является ли файл символической ссылкой.
Другими словами, если родительский элемент ".." является символической ссылкой, вы должны сохранить ее, в противном случае, вероятно, безопасно удалить ее и, вероятно, всегда безопасно удалить ".".
Это похоже на манипулирование фактическая строка, но немного более элегантно.
boost::filesystem::path resolve(
const boost::filesystem::path& p,
const boost::filesystem::path& base = boost::filesystem::current_path())
{
boost::filesystem::path abs_p = boost::filesystem::absolute(p,base);
boost::filesystem::path result;
for(boost::filesystem::path::iterator it=abs_p.begin();
it!=abs_p.end();
++it)
{
if(*it == "..")
{
// /a/b/.. is not necessarily /a if b is a symbolic link
if(boost::filesystem::is_symlink(result) )
result /= *it;
// /a/b/../.. is not /a/b/.. under most circumstances
// We can end up with ..s in our result because of symbolic links
else if(result.filename() == "..")
result /= *it;
// Otherwise it should be safe to resolve the parent
else
result = result.parent_path();
}
else if(*it == ".")
{
// Ignore
}
else
{
// Just cat other path entries
result /= *it;
}
}
return result;
}
Он все еще там. Продолжайте использовать его.
Я полагаю, они отказались от него, потому что символические ссылки означают, что свернутый путь не обязательно эквивалентен. Если c: \ full \ path был символической ссылкой на c: \ грубый , то c: \ full \ path \ .. будет c: \ , а не c: \ full .
объяснение находится на http://www.boost.org/doc/libs/1_40_0/libs/filesystem/doc/design.htm :
Работайте в рамках описанных ниже реалий.
Обоснование: Это не исследовательский проект. Требуется что-то, что работает на современных платформах, включая некоторые встроенные операционные системы с ограниченными файловыми системами. Из-за упора на переносимость такая библиотека была бы намного полезнее, если бы она была стандартизирована. Это означает возможность работать с гораздо более широким спектром платформ, таких как Unix или Windows и их клоны.
где «реальность», применимая к удалению normalize , такова:
Символические ссылки вызывают канонические и нормальная форма некоторых путей для представления различных файлов или каталогов. Например, учитывая иерархию каталогов / a / b / c, с символьной ссылкой в / a с именем x, указывающей на b / c, тогда в соответствии с правилами разрешения путей POSIX путь «/ a / x / ..» должен разрешаться в "/ а / б". Если бы "/ a / x / .." сначала нормализовалось до "/ a", это разрешилось бы неправильно. (Случай предоставлен Уолтером Лэндри.)
библиотека не может действительно нормализовать путь без доступа к базовым файловым системам, что делает операцию а) ненадежной б) непредсказуемой в) неправильной г) всем вышеперечисленным