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

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

·> Да и std::filesystem умеет и win32, которая не posix.
А некоторые версии Windows поддерживают 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++ — универсальный язык.

PNG — ISO 15948
JPEG — ISO/IEC 10918
PDF — ISO 32000-2
Остальные тоже тоже как-то стандартизованы отдельными документами.
Что из перечисленного:
fstream, std::cin, std::cout, atomic, chrono, mutex, random, thread, locale, map, vector, string
описано в отдельном стандарте?

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

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

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 файловой системы, а то как она функционирует — опредеяется реализацией фс.
Скажите, какая цель создания библиотеки std::filesystem ?

·>Это, кстати, заморочки win/ntfs, насколько я понял. Если у тебя где-то под рукой есть Винда, можешь потетстить.
Да неужели?
А вот скажите, для работы с (ex)FAT накопителями, которые, по числу, видимо, превосходят количество накопителей на других форматах файловых систем, библиотека std::filesystem приспособлена хорошо?

BFE>>Я, наоборот, предлагаю экзотические типы сделать implementation-defined.
·>Зачем? Они не такие уж экзотические. Скажем, даже в винде есть "\\.\pipe\".
Уверен, что если провести опрос, то окажется что более 90% программистов никогда в жизни не работали с такими файлами именно как с файлами.

·>Да, кстати, implementation-defined типы тоже поддерживаются.
я знаю.

·>Не очень ясно написано. Напиши тесты, поглядим как сделать имплементацию.
pathName first second
"" "" ""
"/" "/" ""
"a" "" "a"
"/a" "/" "a"
"b/a" "b/" "a"
"a/" "" "a"
"a/." "" "a"
"a/.." "a/.." ""
"/a/b" "/a" "b"
"../b" ".." "b"
"./b" "." "b"

·>Такое и AI сможет сгенерить, наверное.
AI сгенерил код, что зацикливается на некоторых путях.

·>Понятно, но не правильно. Последний компонент path — всегда имя. Каким типом файла является данное имя в данной файловой системе — по пути никак не определить. Чтобы узнать — надо прочитать содержимое фс.
Укажите на имя для пути "/a/" и для пути "/"

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

·>Я же уже объяснил. Пришлось потому что cp может использоваться как интерактивная команда, которую надо по-бырому натапать, так и в скриптах. Причём тут сабж — я не понимаю.
я подожду кода для задачи выше.