Filesystem V3 Design

Boost , ,

Filesystem Version 3 Design

Осторожно:Эта страница документирует мышление в начале процесса разработки V3 и предназначена для исторических целей. Он не обновляется, чтобы отразить текущее состояние библиотеки.

Introduction

Во время обзора Boost.Filesystem.V2 (Интернационализация) Питер Димов предположил, что шаблон класса<basic_path>был громоздким, и что один тип пути, который вмещал несколько типов символов и кодировок, был бы более гибким. Хотя в то время я не хотел останавливать разработку, чтобы исследовать, как эта идея может быть реализована, или вырваться из шаблона интернационализации, используемого стандартной библиотекой C++, я часто думал о предложении Питера. С появлением типов символов C++0x<char16_t>и<char32_t>подход шаблона классов<basic_path>становится еще более громоздким, поэтому пришло время пересмотреть проблему в свете предложения Питера.

Problem

С файловой системой. V2, аргумент пути к определенной пользователем функции, которая предназначена для размещения нескольких типов символов и кодировок, должен быть записан как шаблон. Необходимо использовать перегрузки или метапрограммирование шаблонов, чтобы позволить аргументам быть написанными в виде строковых букв. Вот как это выглядит:

template<class Path>
void foo( const Path & p );

inline void foo( const path & p )
{
  return foo<path>( p );
}
inline void foo( const wpath & p )
{
  return foo<wpath>( p );
}

Это действительно уродливо для такой простой потребности, и был бы комбинаторный взрыв, если бы функция принимала несколько аргументов Пути, и каждый из них мог быть либо узким, либо широким. Еще хуже, если поддерживать типы C++0x<char16_t>и< char32_t>.

Solution

Обзор:

• Единый, без шаблонаclass path.
• Каждая функция-член представляет собой шаблон, вмещающий различные применимые типы символов, включая определяемые пользователем типы символов.
• Удерживайте путь внутри строки типа, используемого API операционной системы;std::stringдля POSIX,std::wstringдля Windows.

Подписи, представленные вПроблемасжимаются до простого:

void foo( const path & p );

Это означает снижение сложности кода. Спецификация также становится проще. Я считаю, что это будет намного проще в обучении и приведет к гораздо более гибкому пользовательскому коду.

Другие преимущества:

• Все полиморфизмы происходят во время компиляции.
• Эффективность повышается, поскольку преобразования кодирования, при необходимости, происходят только один раз во время создания, а не каждый раз, когда используется путь.
• Размер кода реализации падает примерно вдвое и становится гораздо более читаемым.

Возможные проблемы:

• Сочетание шаблонов функций членов и неявных конструкторов может привести к неясным сообщениям об ошибках, когда пользователь делает простые распространенные ошибки кодирования. Это должно быть гораздо меньше проблем с концепциями C++, но в то же время работа продолжает ограничивать агрессивные шаблоны через enable_if/disable_if.

Details

Когда тип аргумента функции пути класса соответствует типу аргумента API операционной системы для путей, не выполняется преобразование, а не преобразование в указанное кодирование, такое как одно из кодировок Unicode. Это позволяет избежать непредвиденных последствий и т.д.

Other changes

Унифицированная гибридная обработка ошибок:Идиома гибридной обработки ошибок последовательно применяется ко всем применимым функциям.

Acknowledgements

Петр Димов предложил идею класса одного пути, который мог бы справиться с несколькими типами символов и кодировками. Уолтер Лэндри внес вклад в разработку и реализацию функций copy_any, copy_directory, copy_symlink и read_symlink.

Пересмотрено29 декабря 201429 December, 2014[ORIG_END] -->

Авторское право Beman Dawes, 2008

Использование, модификация и распространение регулируются Лицензией на программное обеспечение Boost версии 1.0. См.www.boost.org/LICENSE_1_0.txt

Статья Filesystem V3 Design раздела может быть полезна для разработчиков на c++ и boost.

:: Главная :: ::