Основной мотивацией для начала работы над библиотекой файловой системы было разочарование в административных инструментах Boost. Scripts были написаны на языках команд Python, Perl, Bash и Windows. Не было единого языка сценариев, знакомого и приемлемого для всех администраторов Boost. Тем не менее, все они были опытными программистами на C++ - почему C++ не может использоваться в качестве языка сценариев?
Ключевой особенностью C++, которой не хватало для приложений, похожих на скрипты, была возможность выполнять переносные операции файловой системы в каталогах и их содержимом. Библиотека файловых систем была разработана для заполнения этой пустоты.
Цель состоит не в том, чтобы конкурировать с традиционными языками сценариев, а в том, чтобы обеспечить решение для ситуаций, когда C++ уже является языком выбора.
Уметь писать портативные операции файловой системы в стиле скрипта на современном C++.
Обоснование: Это общая потребность в программировании. И смущает, и смущает то, что это невозможно ни с нынешними библиотеками C++, ни с библиотеками Boost. Необходимость особенно остра, когда C++ является единственным набором инструментов, разрешенным в цепочке инструментов. Операции файловой системы обеспечиваются многими языками, используемыми на нескольких платформах, таких как Perl и Python, а также многими языками сценариев платформ. Все операционные системы предоставляют некоторую форму API для операций файловой системы, и POSIX-связи становятся все более доступными даже для операционных систем, обычно не связанных с POSIX, таких как Mac, z/OS или OS/390.
Обоснование: Это не исследовательский проект. Необходимо что-то, что работает на современных платформах, включая некоторые встроенные операционные системы с ограниченными файловыми системами. Из-за акцента на портативность такая библиотека была бы гораздо полезнее при стандартизации. Это означает возможность работать с гораздо более широким спектром платформ, таких как Unix или Windows и их клоны.
Избегайте опасных методов программирования. В частности, слишком легко игнорировать уведомления об ошибках и использование глобальных переменных. Если предоставлена опасная функция, идентифицируйте ее как таковую.
Обоснование: Обычно это покрывается "обычные требования Boost...", но это упоминается явно, потому что эквивалентные интерфейсы родной платформы и языка сценариев часто зависят от слишком простых для игнорирования уведомлений об ошибках и глобальных переменных, таких как "текущий рабочий каталог".
Структурируйте библиотеку так, чтобы она по-прежнему была полезна, даже если некоторые функции плохо отображаются на данной платформе или дереве каталогов. В частности, многие полезные функции должны быть переносимы даже на плоские (не иерархические) файловые системы.
Обоснование: Большая функциональность, которая не требует иерархической структуры каталогов, по-прежнему полезна в файловых системах с плоской структурой. Есть много систем, особенно встроенных, где по-прежнему полезна даже очень ограниченная функциональность.
Интерфейс плавно с текущим C++ Стандартные средства ввода/вывода библиотеки. Например, пути должны быть просты в использовании в конструкторах std::basic_fstream.
Обоснование: Одним из наиболее распространенных применений функциональности файловой системы является манипулирование путями для возможного использования в операциях ввода / вывода. Таким образом, необходимо бесперебойно взаимодействовать со стандартной библиотекой ввода/вывода.
Подходит для возможной стандартизации. Смысл этого требования заключается в том, чтобы интерфейс был близок к минимальному и чтобы была большая осторожность в отношении портативности.
Обоснование: Отсутствие операций файловой системы является серьезной дырой в текущем стандарте, и нет других известных кандидатов для заполнения этой дыры. Библиотеки со сложными интерфейсами и сложными спецификациями портирования гораздо реже принимаются для стандартизации.
Применяются обычные требования и руководящие принципы.
Поощряйте, но не требуйте переносимости в названиях путей.
Обоснование: Для путей, которые исходят из пользовательского ввода, неразумно требовать переносного синтаксиса пути.
Избегайте создавать иллюзию переносимости там, где переносимости на самом деле не существует.
Обоснование: Оставляя важное поведение неопределенным или "определение реализации" оказывает большую плохую услугу программистам, использующим библиотеку, потому что создается впечатление, что код, основанный на поведении, является портативным, когда на самом деле в нем нет ничего портативного. Единственный случай, когда такая спецификация приемлема, это когда и пользователи, и разработчики точно знают из других источников, какое поведение требуется, но по какой-то причине невозможно точно указать его.
Некоторые операционные системы имеют один корень дерева каталогов, другие имеют несколько корней.
Некоторые файловые системы предоставляют как длинную, так и короткую форму имен файлов.
Некоторые файловые системы имеют различный синтаксис для путей файлов и путей каталогов.
Некоторые файловые системы имеют разные правила для действительных имен файлов и действительных имен каталогов.
Некоторые файловые системы (ISO-9660, уровень 1, например) используют очень ограниченные (так называемые 8.3) имена файлов.
Некоторые операционные системы позволяют файловым системам с различными характеристиками быть смонтированными в дерево каталогов. Таким образом, файловая система ISO-9660 или Windows может оказаться поддеревом дерева каталогов POSIX.
Широкохарактерные версии каталогов и файловых операций доступны в одних операционных системах, а в других недоступны.
Нет закона, который говорит, что иерархии каталогов должны быть указаны с точки зрения приличия слева направо от корня.
Некоторые файловые системы имеют концепцию файла "version number" или "generation number". .
Не все операционные системы используют отдельные разделители символов в именах путей. Некоторые используют парные обозначения. Типичное полное имя файла OpenVMS может выглядеть примерно так:
Для обычных файловых систем определение того, являются ли два дескриптора одним и тем же объектом, чрезвычайно сложно или невозможно. Например, понятие равенства может быть различным для каждой части пути — некоторые части могут быть чувствительными к случаю или локализации, другие — нет. Чувствительность кейса является свойством самого названия пути, а не платформы. Определить коллационную последовательность еще хуже.
Могут возникнуть расовые условия. Деревья каталогов, каталоги, файлы и атрибуты файлов фактически разделены между всеми потоками, процессами и компьютерами, которые имеют доступ к файловой системе. Это может включать компьютеры на другой стороне мира или на орбите вокруг света. Это означает, что операции файловой системы могут выйти из строя неожиданным образом. Например:
assert( exists("foo") == exists("foo") );
// may fail!
assert( is_directory("foo") == is_directory("foo");
// may fail!
В первом примере файл может быть удален между вызовами к существованию(). Во втором примере файл может быть удален, а затем заменен каталогом с тем же именем между вызовами на is_directory().
Несмотря на то, что приложение может быть портативным, ему все равно придется время от времени отправлять трафик по определенным путям системы; пользовательский ввод является общим примером.
Символическиессылки вызывают каноническую и нормальную форму некоторых путей для представления различных файлов или каталогов. Например, учитывая иерархию каталогов/a/b/c, с символической ссылкой в/aпод названиемx указывая наb/c, то в соответствии с правилами POSIX Pathname Resolution путь"/a/x/.."должен разрешаться до"/a/b". Если бы"/a/x/.."было сначала нормализовано до"/a", то это разрешилось бы неправильно. (перенаправлено с «Walter Landry»)
ТребованияиРеалиивыше привели к большей части дизайна интерфейса C++. В частности, желание сделать скриптовый код простым вызвало много усилий, чтобы убедиться, что, по-видимому, простые выражения, такие как, существуют.
См.FAQдля обоснования многих подробных проектных решений.
Несколько ключевых идей вошли впутьдизайна класса:
Разъединение входных форматов, внутренней концептуальной модели (векторнойили другой последовательности) и выходных форматов.
Обеспечивая два входных формата (общий и O / S специфичный) сломали главный тупик дизайна.
Предоставление нескольких выходных форматов решило еще один набор ранее неразрешимых проблем.
Для поддержки портативного кода требуется несколько неочевидных функций (особенно разложение и состав). (Питер Димов, Томас Витт, Глен Ноулз, другие.)
Проверка ошибок была особенно сложной областью. Одним из ключевых выводов было то, что с именами файлов и каталогов переносимость не является универсальной истиной. Скорее, программист должен продумать вопрос "Какие операционные системы я хочу, чтобы этот путь был портативным? " Обеспечивая поддержку нескольких ответов на этот вопрос, библиотека файловой системы предупреждает программистов о необходимости задать его.
Оригинальный дизайн и реализация Dietmar Kühl поддерживали имена файлов и каталогов с широкими символами. От него отказались после того, как участники библиотечной рабочей группы не смогли определить портативную семантику для широкохарактерных имен в системах, не обеспечивающих нативную поддержку. См.FAQ.
Предыдущие итерации дизайна интерфейса использовали явно названные функции, обеспечивающие большое количество удобных операций, без опций времени компиляции или времени выполнения. Было так много названий функций, что они были очень запутанными в использовании, а интерфейс был намного больше. Любые преимущества казались скорее теоретическими, чем реальными.
Конструкции, основанные на времени компиляции (а не на времени выполнения), флаге и выборе опций (через политику, enum или параметры шаблона int), стали настолько сложными, что от них отказались, часто после вложения довольно много времени и усилий. Необходимость квалифицировать имена атрибутов или опций с пробелами имен, даже псевдонимами, используется в шаблонных параметрах; это не было полностью оценено до написания реального кода.
Еще один набор функций удобства (например,убратьс разрешительными, обрезными, повторяющимися и другими опциями, плюс предикат и, возможно, другие функции фильтрации) был оставлен, потому что детали стали сложными и спорными.
Остается инструментарий низкоуровневых операций, из которого пользователь может создавать более сложные операции удобства, а также очень небольшое количество функций удобства, которые оказались достаточно полезными для оправдания включения.
path.hpp
Было так много заброшенных дорожек, что я потерял след. Шаблоны классов, основанные на политике, в нескольких вариантах, конструкторы поставляли политики времени выполнения, конкретные политики времени выполнения, все они рассматривались, часто реализовывались и в конечном итоге отказывались как слишком сложные для любых небольших наблюдаемых преимуществ.
От ряда конструкций механизмов проверки ошибок отказались, некоторые после экспериментов с реализациями. В частности, была предпринята попытка автоматической проверки ошибок. Но автоматическая проверка ошибок, как правило, значительно усложняет общий дизайн библиотеки.
Некоторые конструкции связывают механизмы проверки ошибок с путями. Некоторые из них имеют операционные функции. Был частично реализован дизайн шаблона, основанный на политике проверки ошибок, а затем оставлен как слишком сложный для повседневных программ, похожих на скрипты.
Конечный дизайн, который частично зависит от явных вызовов функции проверки ошибок, намного проще и проще, хотя он в некоторой степени зависит от дисциплины программиста. Но это должно позволить программистам, которые обеспокоены переносимостью, быть достаточно уверенными в том, что их программы будут правильно работать над выбором целевых систем.
IEEE Std 1003.1-2001, ISO/IEC 9945:2002, and The Open Group Base Specifications, Issue 6. Also known as The
Single Unix® Specification, Version 3.
Available from each of the organizations involved in its creation. For
example, read online or download from
www.unix.org/single_unix_specification/. The ISO JTC1/SC22/WG15 - POSIX
homepage is
www.open-std.org/jtc1/sc22/WG15/
William Wulf, Mary Shaw, Global
Variable Considered Harmful, ACM SIGPLAN Notices, 8, 2, 1973, pp. 23-34
Пересмотрено26 Декабря 201426 December, 2014[ORIG_END] -->
Авторское право Beman Dawes, 2002
Использование, модификация и распространение регулируются Лицензией на программное обеспечение Boost версии 1.0. (См. сопроводительный файлLICENSE_1_0.txtили копию наwww.boost.org/LICENSE_1_0.txt)
Статья Boost Filesystem Library Design раздела может быть полезна для разработчиков на c++ и boost.
Filesystem
Library Design