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

BFE>·>Ты же сам ответил на свой вопрос: разработка std::filesystem базировалась на этом взятом из UNIX систем стандарте. Очевидно же.
BFE>Это не ответ на мой вопрос.
BFE>Зачем в стандарт языка тащить стандарт API системы?
posix — это не api конкретной системы.

BFE>Может тогда в стандарт языка ещё и все остальные стандарты добавить? Стандарт USB, стандарт DVD, стандарт Bluetooth, PNG, JPEG, SVG, PDF...
В эту игру могут играть двое. А зачем в стандарт языка притащили fstream? Да тот же std::cin/std::cout — вполне себе очень даже API системы. В ту же степь atomic, chrono, mutex, random, thread. И заодно выкинем locale, map, vector, string — какое это всё имеет отношение к языку С++ ? Ведь это всё — это только часть возможного приложения языка, а C++ — универсальный язык.

BFE>·>Потому что и POSIX — стандарт.
BFE>А ещё бывает стандарт Ada.
Это же ЯП. Не понимаю я таких аргументов.

BFE>POSIX — это только часть возможного приложения языка, а C++ — универсальный язык. Хотите добавить что-то специфичное, то так и назовите std::posix_filesystem
А я понимаю: ты путаешь ЯП и стандартную библиотеку. Так вот... std — это стандартная библиотека языка, а не язык.

BFE>>>Или, вот ссылки, к примеру. В документации сказано, что ссылку на директорию и ссылку на файл надо создавать разными функциями здесь.
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>Именно это я и написал.
Но ты, похоже, не понял почему надо.

BFE>·> Что в лоб, что по лбу. Потому что ссылка содержит в себе путь, а не файл или директорию.
BFE> Ладно, если вы не понимаете словами, попробую описать задачу. У вас есть символьная ссылка, то на что она указывает не существует. Вопрос: как создать тот путь, на который она указывает, чтобы не нарушить требование выше: "Portable code should use (3,4)"
Изучай доки как файловая система работает. Задача std — обеспечить стандартизованый доступ к API файловой системы, а то как она функционирует — опредеяется реализацией фс.
Это, кстати, заморочки win/ntfs, насколько я понял. Если у тебя где-то под рукой есть Винда, можешь потетстить.

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

BFE>>> Значит написать такую функцию просто? Напишите?
BFE>·>Непонятно что именно такая функция должна делать в разных сценариях и зачем. Для извлечения разных компонент пути есть функции parent_path, relative_path, filename и т.п.
BFE>Зачем? Я уже писал выше по ветке здесь

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

. То, что она должна возвращать там тоже написано.
Не очень ясно написано. Напиши тесты, поглядим как сделать имплементацию. Такое и AI сможет сгенерить, наверное.

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

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

BFE>Удивительно, правда?
BFE>Из-за плохо выбранного способа записи пути пришлось в утилиту cp добавить специальные опции. Это привело к увеличению кода. О чём я и писал. Так зачем этот кривой формат втащили в стандарт языка?
Я же уже объяснил. Пришлось потому что cp может использоваться как интерактивная команда, которую надо по-бырому натапать, так и в скриптах. Причём тут сабж — я не понимаю.

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

BFE>·>Ты же сам ответил на свой вопрос: разработка std::filesystem базировалась на этом взятом из UNIX систем стандарте. Очевидно же.
BFE>Это не ответ на мой вопрос.
BFE>Зачем в стандарт языка тащить стандарт API системы?
posix — это не api конкретной системы. Да и std::filesystem умеет и win32, которая не posix.

BFE>Может тогда в стандарт языка ещё и все остальные стандарты добавить? Стандарт USB, стандарт DVD, стандарт Bluetooth, PNG, JPEG, SVG, PDF...
В эту игру могут играть двое. А зачем в стандарт языка притащили fstream? Да тот же std::cin/std::cout — вполне себе очень даже API системы. В ту же степь atomic, chrono, mutex, random, thread. И заодно выкинем locale, map, vector, string — какое это всё имеет отношение к языку С++ ? Ведь это всё — это только часть возможного приложения языка, а C++ — универсальный язык.

BFE>·>Потому что и POSIX — стандарт.
BFE>А ещё бывает стандарт Ada.
Это же ЯП. Не понимаю я таких аргументов.

BFE>POSIX — это только часть возможного приложения языка, а C++ — универсальный язык. Хотите добавить что-то специфичное, то так и назовите std::posix_filesystem
А я понимаю: ты путаешь ЯП и стандартную библиотеку. Так вот... std — это стандартная библиотека языка, а не язык.

BFE>>>Или, вот ссылки, к примеру. В документации сказано, что ссылку на директорию и ссылку на файл надо создавать разными функциями здесь.
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>Именно это я и написал.
Но ты, похоже, не понял почему надо.

BFE>·> Что в лоб, что по лбу. Потому что ссылка содержит в себе путь, а не файл или директорию.
BFE> Ладно, если вы не понимаете словами, попробую описать задачу. У вас есть символьная ссылка, то на что она указывает не существует. Вопрос: как создать тот путь, на который она указывает, чтобы не нарушить требование выше: "Portable code should use (3,4)"
Изучай доки как файловая система работает. Задача std — обеспечить стандартизованый доступ к API файловой системы, а то как она функционирует — опредеяется реализацией фс.
Это, кстати, заморочки win/ntfs, насколько я понял. Если у тебя где-то под рукой есть Винда, можешь потетстить.

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

BFE>>> Значит написать такую функцию просто? Напишите?
BFE>·>Непонятно что именно такая функция должна делать в разных сценариях и зачем. Для извлечения разных компонент пути есть функции parent_path, relative_path, filename и т.п.
BFE>Зачем? Я уже писал выше по ветке здесь

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

. То, что она должна возвращать там тоже написано.
Не очень ясно написано. Напиши тесты, поглядим как сделать имплементацию. Такое и AI сможет сгенерить, наверное.

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

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

BFE>Удивительно, правда?
BFE>Из-за плохо выбранного способа записи пути пришлось в утилиту cp добавить специальные опции. Это привело к увеличению кода. О чём я и писал. Так зачем этот кривой формат втащили в стандарт языка?
Я же уже объяснил. Пришлось потому что cp может использоваться как интерактивная команда, которую надо по-бырому натапать, так и в скриптах. Причём тут сабж — я не понимаю.