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

BFE>До тех пор, пока идёт работа с отдельными файлами, особых сложностей не возникает, но если начинается работа с каталогами...

Я думаю, этой хрени хватит, например, чтобы написать архиватор.

BFE>Ну, например, в общем случае нет возможности получить список файлов каталога. Единственный способ — это пытаться использовать std::filesystem::directory_iterator, но в процессе перечисления файлов операция инкремента может завершится с ошибкой, например потому, что следующий файл был удалён (или добавлен, это не специфицировано) другим процессом.

Я подозреваю, что в UNIX этот итератор просто зовёт readdir. readdir не завершится с ошибкой от того, что другой процесс создал или удалил файл. Но может не заметить изменений в директории.

BFE>В этом случае процесс перечисления надо начинать заново. На больших каталогах, где постоянно добавляются/удаляются файлы это процесс до конца вообще, наверно, никогда не дойдёт.

Итерирование директории, в которой постоянно происходит какая-то жизнь, даже на уровне системных вызовов нетривиально и нуждается в тщательном продумывании.

К тому, что на уровне сисколов непросто, стандартная библиотека вряд ли сможет приделать более простую абстракции. К тому же, стандартная библиотека должна изображать из себя что-то нейтральное по отношению к ОС.

BFE>Или, например, std::filesystem::path не различает имя файла и имя каталога. Вернее так: имя файла и имя директории — это один и тот же объект: std::filesystem::path. Это не удобно использовать. Было бы логично иметь три типа объектов: путь, имя файла и путь_с_файлом.

UNIX их тоже не различает. Нужно отдельно stat говорить. Становится понятно, откуда уши торчат

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

BFE>Верно, что для записи "/a/b/c" — невозможно сказать, является ли "c" файлом или директорией. А вот для записи "/a/b/c/" — можно. Было бы логично определить, что все пути заканчивающиеся разделителем не являются файлами, а все не заканчивающиеся разделителями — содержат в конце имя файла. Тогда:

Ты сейчас предлагаешь способ именования файлов, не похожий ни на одну существующую операционную систему.

Это означает, если его использовать, в любой ОС будет неудобно. Хотя, наверное, и справедливо, никому не будет обидно.

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

BFE>>>>Зачем в стандарт языка тащить стандарт API системы?
BFE>>·>posix — это не api конкретной системы.
BFE>>Да.
·>Т.е. твоя идея std::posix_filesystem — не состоятельна и "Зачем в стандарт языка тащить стандарт API системы" — дурацкий вопрос.
Почему дурацкий? std::filesystem не является универсальной. Так? Она годится только для posix совместимых файловых систем. Тогда почему она не называется std::posix_filesystem ?

BFE>>Остальные тоже тоже как-то стандартизованы отдельными документами.
·>И что?
Для них для всех надо добавлять классы в С++ стандарт?

BFE>>Что из перечисленного:
BFE>>fstream, std::cin, std::cout, atomic, chrono, mutex, random, thread, locale, map, vector, string
BFE>>описано в отдельном стандарте?
·>Не знаю. А какая разница? Разбираться лень, но например thread по сути поделие для замены posix-тредов.
·>Кстати, а в каком отдельном стандарте описано std::filesystem?
Видно, что вам лень разбираться.

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

BFE>>>>POSIX — это только часть возможного приложения языка, а C++ — универсальный язык. Хотите добавить что-то специфичное, то так и назовите std::posix_filesystem
BFE>>·>А я понимаю: ты путаешь ЯП и стандартную библиотеку. Так вот... std — это стандартная библиотека языка, а не язык.
BFE>>std библиотека описана в том же стандарте, что и сам язык. Более того, некоторые части std библиотеки являются неотъемлемой часть языка, например std::initializer_list.
·>И что? И кто из fstream, std::cin, std::cout, atomic, chrono, mutex, random, thread, locale, map, vector, string является неотъемлемой часть языка?
То, что все остальные являются универсальными, а std::filesystem — нет.

BFE>>>> Ладно, если вы не понимаете словами, попробую описать задачу. У вас есть символьная ссылка, то на что она указывает не существует. Вопрос: как создать тот путь, на который она указывает, чтобы не нарушить требование выше: "Portable code should use (3,4)"
BFE>>·>Изучай доки как файловая система работает. Задача std — обеспечить стандартизованый доступ к API файловой системы, а то как она функционирует — опредеяется реализацией фс.
BFE>>Скажите, какая цель создания библиотеки std::filesystem ?
·>Такая же как у fstream, std::cin, std::cout, atomic, chrono, mutex, random, thread, locale, map, vector, string.
Не похоже.

BFE>>·>Это, кстати, заморочки win/ntfs, насколько я понял. Если у тебя где-то под рукой есть Винда, можешь потетстить.
BFE>>Да неужели?
·>Ну да.
И как эти заморочки решены в std::filesystem ?

BFE>>А вот скажите, для работы с (ex)FAT накопителями, которые, по числу, видимо, превосходят количество накопителей на других форматах файловых систем, библиотека std::filesystem приспособлена хорошо?
·>define "хорошо". И что, по-твоему, приспособлено лучше?
Хорошо — значит содержит возможность удобно работать с файловой системой и делать это так же, как и с другими файловыми системами в той части в которой их функциональность совпадает.

BFE>>·>Зачем? Они не такие уж экзотические. Скажем, даже в винде есть "\\.\pipe\".
BFE>>Уверен, что если провести опрос, то окажется что более 90% программистов никогда в жизни не работали с такими файлами именно как с файлами.
·>И что?
std::filesystem их поддерживает?

BFE>>·>Да, кстати, implementation-defined типы тоже поддерживаются.
BFE>>я знаю.
·>А в чём тогда претензия?
Почему все эти специфичные для posix систем типы не implementation-defined ? Как их поддерживать для FAT систем?

BFE>>·>Не очень ясно написано. Напиши тесты, поглядим как сделать имплементацию.
BFE>>pathName first second
BFE>>"" "" ""
BFE>>"/" "/" ""
BFE>>"a" "" "a"
BFE>>"/a" "/" "a"
BFE>>"b/a" "b/" "a"
BFE>>"a/" "" "a"
BFE>>"a/." "" "a"
BFE>>"a/.." "a/.." ""
BFE>>"/a/b" "/a" "b"
BFE>>"../b" ".." "b"
BFE>>"./b" "." "b"
·>Это просто parent_path и filename.
Нет.
·>Вот только почему-то ты хочешь случайно расставленные / с неясно какой целью. Добавляй их сам.
Не случайно.
·> Я логику не улавливаю.
Что вам не понятно?
Возвращаемое значение должно быть вида {путь, имя}, где имя — это последнее имя в pathName, а путь — это то, что перед ним. Имя должно быть пустым, если его нельзя вычленить.

·>Покажи решение на ЯП/либе, в которых, есть по-твоему правльно реализованный path.
Это вы грозились мне её написать.

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

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

BFE>>rust уже стандартизовали?
·>Не знаю. А какая разница?
Для меня есть большая разница. Я стараюсь избегать использование языков без стандарта.

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

BFE>>>Да.
BFE>·>Т.е. твоя идея std::posix_filesystem — не состоятельна и "Зачем в стандарт языка тащить стандарт API системы" — дурацкий вопрос.
BFE>Почему дурацкий? std::filesystem не является универсальной. Так? Она годится только для posix совместимых файловых систем.
Даже какой-нибудь банальный std::map тоже не является универсальным. И что?

BFE> Тогда почему она не называется std::posix_filesystem ?
Я уже отвечал на этот вопрос. Потому что она умеет не только posix, но и в winapi например.

BFE>>>Остальные тоже тоже как-то стандартизованы отдельными документами.
BFE>·>И что?
BFE>Для них для всех надо добавлять классы в С++ стандарт?
Нет, не надо.

BFE>·>Не знаю. А какая разница? Разбираться лень, но например thread по сути поделие для замены posix-тредов.
BFE>·>Кстати, а в каком отдельном стандарте описано std::filesystem?
BFE>Видно, что вам лень разбираться.
Потому что это твоё словоблудие про стандарты, ты и парься.

BFE>>>По какому критерию выбран именно этот стандарт для добавления в C++, а не какой-то другой?
BFE>·>Понятия не имею. А какая разница?
BFE>Проблема в том, что библиотека std::filesystem получилась весьма специфичной, да ещё и кривой.
Допустим. Так причём тут критерии выбора?

BFE>>>·>А я понимаю: ты путаешь ЯП и стандартную библиотеку. Так вот... std — это стандартная библиотека языка, а не язык.
BFE>>>std библиотека описана в том же стандарте, что и сам язык. Более того, некоторые части std библиотеки являются неотъемлемой часть языка, например std::initializer_list.
BFE>·>И что? И кто из fstream, std::cin, std::cout, atomic, chrono, mutex, random, thread, locale, map, vector, string является неотъемлемой часть языка?
BFE>То, что все остальные являются универсальными, а std::filesystem — нет.
В каком месте оно универсальнее? Как мне, например, универсально через какой-нибудь std::cin ввести пароль без echo с консоли?

BFE>>>·>Изучай доки как файловая система работает. Задача std — обеспечить стандартизованый доступ к API файловой системы, а то как она функционирует — опредеяется реализацией фс.
BFE>>>Скажите, какая цель создания библиотеки std::filesystem ?
BFE>·>Такая же как у fstream, std::cin, std::cout, atomic, chrono, mutex, random, thread, locale, map, vector, string.
BFE>Не похоже.
В чём не похоже?

BFE>>>·>Это, кстати, заморочки win/ntfs, насколько я понял. Если у тебя где-то под рукой есть Винда, можешь потетстить.
BFE>>>Да неужели?
BFE>·>Ну да.
BFE>И как эти заморочки решены в std::filesystem ?
В доке написано же: "Portable code should use (3,4)".

BFE>>>А вот скажите, для работы с (ex)FAT накопителями, которые, по числу, видимо, превосходят количество накопителей на других форматах файловых систем, библиотека std::filesystem приспособлена хорошо?
BFE>·>define "хорошо". И что, по-твоему, приспособлено лучше?
BFE>Хорошо — значит содержит возможность удобно работать с файловой системой и делать это так же, как и с другими файловыми системами в той части в которой их функциональность совпадает.
Какой части std:filesystem не приспособлена хорошо по этому твоему определению?
И ты проигнорировал вопрос: "что, по-твоему, приспособлено лучше?".

BFE>>>Уверен, что если провести опрос, то окажется что более 90% программистов никогда в жизни не работали с такими файлами именно как с файлами.
BFE>·>И что?
BFE>std::filesystem их поддерживает?
Да, насколько я знаю.

BFE>>>я знаю.
BFE>·>А в чём тогда претензия?
BFE>Почему все эти специфичные для posix систем типы не implementation-defined ? Как их поддерживать для FAT систем?
Не возвращать значения этих типов.

BFE>·>Это просто parent_path и filename.
BFE>Нет.
Ну ещё возможно has_filename или ещё какой-нибдуь has_X.

BFE>·> Я логику не улавливаю.
BFE>Что вам не понятно?
BFE>Возвращаемое значение должно быть вида {путь, имя}, где имя — это последнее имя в pathName, а путь — это то, что перед ним. Имя должно быть пустым, если его нельзя вычленить.
Ну, например, в пути "a/" — последнее имя (ака filename) отсутствует, его нельзя вычленить. Та же ситуация, что и для "/a/" и "/". Но ты выше захотел внезапно "a/" -> {"", "a"}. Где у тебя логика?

BFE>·>Покажи решение на ЯП/либе, в которых, есть по-твоему правльно реализованный path.
BFE> Это вы грозились мне её написать.
Я утверждал, что твою логику (если она действительно есть) можно написать на std::filesystem. Твой тезис был, что он слишком крив. Вот только что же ты считаешь некривым — ты тщательно скрываешь.

BFE>·>В данных путях его нет, has_filename возвращает false.
BFE>Значит, таки, определить является ли имя файлом или каталогом можно по виду пути?
У тебя со зрением плохо? Ещё раз. "filename" это не то же самое что "file". И про каталоги у меня речи не шло. Ещё раз: это путь без имени файла. И ещё раз напомню: каталог — это тоже файл.

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

BFE>>>rust уже стандартизовали?
BFE>·>Не знаю. А какая разница?
BFE>Для меня есть большая разница. Я стараюсь избегать использование языков без стандарта.
Это твои личные заморочки. Решай этот вопрос с личным психологом.