Здравствуйте, ·, Вы писали:

BFE>>В общем лично у меня много вопросов к тому, почему std::filesystem выглядит так, а не иначе.
·>Ты же сам ответил на свой вопрос: разработка std::filesystem базировалась на этом взятом из UNIX систем стандарте. Очевидно же.
Это не ответ на мой вопрос.
Зачем в стандарт языка тащить стандарт API системы? Может тогда в стандарт языка ещё и все остальные стандарты добавить? Стандарт USB, стандарт DVD, стандарт Bluetooth, PNG, JPEG, SVG, PDF...

BFE>>·>А ещё бывают другие типы файлов — ссылки, сокеты, пайпы, етс.
BFE>>Во-во. "Смешались к кучу кони, люди...". Зачем это протащили в стандарт? Почему эти типы файлов не implementation defined?
·>Потому что и POSIX — стандарт.
А ещё бывает стандарт Ada. Не понимаю я таких аргументов. POSIX — это только часть возможного приложения языка, а C++ — универсальный язык. Хотите добавить что-то специфичное, то так и назовите std::posix_filesystem

BFE>>Или, вот ссылки, к примеру. В документации сказано, что ссылку на директорию и ссылку на файл надо создавать разными функциями здесь.
·>Там же написано: Some operating systems require symlink creation to identify that the link is to a directory. Portable code should use (3,4) to create directory symlinks rather than (1,2), even though there is no distinction on POSIX systems.
Именно это я и написал.

BFE>>Однако, если ссылка уже создана, то узнать, является ли она ссылкой на файл или директорию невозможно, если таргет был удалён.
·> Что в лоб, что по лбу. Потому что ссылка содержит в себе путь, а не файл или директорию.
Ладно, если вы не понимаете словами, попробую описать задачу. У вас есть символьная ссылка, то на что она указывает не существует. Вопрос: как создать тот путь, на который она указывает, чтобы не нарушить требование выше: "Portable code should use (3,4)"

BFE>>В std::filesystem::file_type просто отсутствует соответствующий тип!
·>А ещё ссылка может ссылаться на сокет. Или даже на ссылку! Сколько ты предложишь добавить ещё типов?
Я, наоборот, предлагаю экзотические типы сделать implementation-defined.

BFE>>>>Возвращаемое значение должно быть вида {путь, имя}, где имя — это последнее имя в pathName, а путь — это то, что перед ним. Имя должно быть пустым, если его нельзя вычленить.
BFE>>·>У path как правило есть методы "взять имя" и "взять родительский путь". По сути — части после последнего "/" и до.
BFE>> Значит написать такую функцию просто? Напишите?
·>Непонятно что именно такая функция должна делать в разных сценариях и зачем. Для извлечения разных компонент пути есть функции parent_path, relative_path, filename и т.п.
Зачем? Я уже писал выше по ветке здесь

Автор: B0FEE664
Дата: 16.07 19:12

. То, что она должна возвращать там тоже написано.

BFE>>>>Из-за того, что std::filesystem::path может быть и файлом и путём,
BFE>>·>Нет. path может быть только путём. Посмотри в словаре значение слова "path".
BFE>>Посмотрел:
BFE>>

BFE>>A path (or filepath, file path, pathname, or similar) is a text string that uniquely specifies an item in a hierarchical file system. Generally, a path is composed of directory names, special directory specifiers and optionally a filename, separated by delimiting text.

BFE>>
·>Ну. И? Перевожу: одним из компонентов пути может быть файловое имя (filename), а не файл. Т.е. откуда ты придумал, что path может быть файлом — я понятия не имею. Для файлов есть например совсем другой тип — std::FILE. Для определения является ли данное имя обычным файлом (regular file), директорией или чем-то ещё — тебе уже необходимо прочитать содержимое файловой системы по данному пути.
Хорошо, я переформулирую:
Из-за того, что std::filesystem::path может ссылаться (указывать, содержать последним компонентом) и файл и на каталог. Так понятно?

BFE>>Там ещё есть интересная таблица. Хочется пожелать удачи авторам std::filesystem в имплантации их библиотеки на всех перечисленных системах...
·> к чему это.
К универсальности языка C++.

BFE>>Действительно, ведь для ключей "-t и -T" дополнительный код писать не надо.
·>Шо?
Удивительно, правда?
Из-за плохо выбранного способа записи пути пришлось в утилиту cp добавить специальные опции. Это привело к увеличению кода. О чём я и писал. Так зачем этот кривой формат втащили в стандарт языка?