Работа с ФС средствами pure C++

https://en.cppreference.com/w/cpp/filesystem

STL сложно назвать чем-то более вменяемым, чем сишный stdio

iostream/fstream ещё значительно медленнее чем stdio.h в большинстве реализаций.

А про скорость вроде и не спрашивали :)

Возможно ли в принципе заменить все эти fopen, fclose и так далее чем-то более вменяемым, например из состава C++ filesystem? Если нет, какой минимальный набор функций для этого еще нужен?

Посмотрите кроссплатформенные проекты.
В них файловый API, обязан быть.

Что ты понимаешь под вменяемостью?

Известные мне проблемы stdio решаются переходом на posix api open(), close(), read() итд. Но С++ тут ни при чём.

От char* и прочего наследия сей хочу избавиться.

c++ std::filesystem это для манипулирования обьектами файловой системы, а не для чтения-записи файлов.

для читки/писки надо пользоваться либо потоками fstream https://en.cppreference.com/w/cpp/header/fstream

либо писать враперы над fread, fwrite… то есть делать свои потоки, либо напрямую fopen, fread…

Для бинарных данных, у fstream есть методы readsome, write. Его же не обязательно использовать только через <<.

Для форматирования текста, есть fmtlib.

От char* и прочего наследия сей хочу избавиться.

В каком смысле?

Для замены манипуляций с char* есть std::string, std::vector<char>, std::array<char, N>.

iostream/fstream ещё значительно медленнее чем stdio.h в большинстве реализаций.

На форматированном вводе/выводе я получал обратные результаты - крестовый вывод быстрее. Думаю, что связано с тем, что в си нужно парсить format string.

Подробности? Звучит странно, зачем от него избавляться, не модно стало?

Уже далеко не семидесятые на дворе и даже тогда ценилось безопасное программирование. Как раз к нему и хочется прийти, иметь гарантированное выделение и освобождение ресурсов ФС, учет ее особенностей (тот же Юникод) и так далее.

Уже далеко не семидесятые

https://en.cppreference.com/w/cpp/io

Используй std::fstream, для путей есть std::filesystem::path.

Уже далеко не семидесятые на дворе и даже тогда ценилось безопасное программирование. Как раз к нему и хочется прийти, иметь гарантированное выделение и освобождение ресурсов ФС, учет ее особенностей (тот же Юникод) и так далее.

Мне кажется, как ни извивайся, это - не про плюсы.

На дваре давно не семидесятые: хочешь не думать о памяти - хреначь на питоне или жс, памяти нынче много, процы бешеные, авось прожует. Ну если что нищебродами несогласных обзовешь - все так делают, чего стыдиться? :)

Для замены манипуляций с char* есть std::string, std::vector, std::array<char, N>.

Еще std::string_view

Не понимаю каким боком тут освобождение/взятие ресурсов, нужно всего лишь дать чаровый указатель io функциям на буфер. Ну да ладно, видимо я слишком «старомоден», сейчас это нужно обмазать 3 абстракциями сверху.

На форматированном вводе/выводе я получал обратные результаты - крестовый вывод быстрее

Вот здесь писал Как читать буфер памяти посимвольно в заданной кодировке? (комментарий) . Крестовый io ещё ведь дополнительно буферезируется, там системных вызовов должно быть меньше по идее.

Можно взять Qt. Там бонусом будет адекватная работа со строками.

https://github.com/ned14/llfio когда-нибудь войдёт в состав Boost. Возможно. :)

Не ну тогда весь си это анархизм, и надо переходить на rust, если уж очень надо лоу левел, там да безопасно будет

Но есть ньюанс…

Звучит странно, зачем от него избавляться, не модно стало?

Затем же, зачем нужно избавляться от raw pointer’ов других типов - чтобы сделать очевидной модель владения и исключить ошибки с управлением памятью.

Не ну тогда весь си это анархизм, и надо переходить на rust, если уж очень надо лоу левел, там да безопасно будет

Для борьбы с ЗППП не обязательно использовать кастрацию, есть альтернативы.

iostream/fstream/filesystem и вот это на false

https://en.cppreference.com/w/cpp/io/ios_base/sync_with_stdio

Ещё нужно забыть про std::endl, в любых случаях где буфер не флашится

Я не разделяю вашу обеспокоенность, это всего лишь указатель, он ничем не владеет, один фиг что обобщенный итератор из стл. Если нужно передавать с владением, то передается юник_птр и смежное. Я в своём коде даже new не пишу, все через make_unique/… . Автор сам себе проблему выдумал и беcпочвенно обвинил в этом char* и лохматые годы.

Но stdio использует не только невладеющие указатели. При использовании функций типа scanf, например, ошибиться намного легче, чем в случае istream.

Необходимость явного вызова fclose после fopen - тоже вполне реальная проблема. Конечно, она легко решается применением своих или чужих RAII-оберток, но у iostream она изначально отсутствует.

Необходимость явного вызова fclose после fopen - тоже вполне реальная проблема.

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

Так я же не против плюсовых потоков, хорошая штука, я бы её и юзал. Более того, отметил их скорость работы в тесте. Только они ведь тоже могут брать указатель на чар - unformat read/write, когда нужно передать буфер.

Указатель на чар особый тип, которому разрешено алиасить что угодно, бояться его не надо. А при виде указателя не надо думать что он обязательно чем-то владеет (надо думать, что он ничем не владеет, просто указатель). Владеют чем-то vector, smart_ptr etc.

Не все пишут hello world’ы, работа с файлами может быть более сложной, чем открытие одного файла в начале функции и закрытие в конце. Даже при минимальном усложнении, например, если у функции есть несколько точек выхода (что критично для читаемости кода), уже возникают неприятности.

А при виде указателя не надо думать что он обязательно чем-то владеет

Ключевое слово «обязательно». Он может владеть, а может и не владеть, и нужно это вовремя распознать. А в случае со ссылками и умными указателями модель владения можно сделать очевидной.

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

Не знаю, если вам известны программисты, которые в голых указателях что-то владеют и считают это нормой, то плюньте в него, скажите, что от меня ). В старом коде такое можно встретить, но писать так сейчас - глупость. Тот же unique_ptr позволяет привязать свой deleter, если ресурс какой-то экзотический, все возможности, move, всё удобно.

Даже при минимальном усложнении, например, если у функции есть несколько точек выхода (что критично для читаемости кода), уже в возникают неприятности.

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

это будет эмуляция raii руками, поскольку другого красивого способа нет.

но в плюсах raii есть, потому так делать не надо. а вот в си - надо

на С++ не работают с файловыми системами. На плюсах объектам указывают политики хранения и кэширования.

на С++ не работают с файловыми системами.

это заявка на рекорд.

на С++ не работают с файловыми системами

А файлы аист приносит?

А файлы аист приносит?

если FILE * или fstream<> то дятел :-)

на плюсах полезны более высокие абстракции

на плюсах полезны более высокие абстракции

уровень абстракций зависит от предметной области, высокие абстракции сами по себе есть схоластика.

Ты хочешь играть в Дарку Соулу, но так, чтобы тебя не били. И какой в этом смысл?

работа с файлами может быть более сложной

1. Открыл

2. Почитал или пописал

3. Закрыл.

Всё остальное - ересь. Числа молотить надо либо до либо после

Тебе никто не сказал про #include <fstream>? Это и есть замена сишного чтения/записи файла. Там есть ifstream, ofstream и просто fstream.

А <filesystem> он немного про другое.

Ещё бывает позиционирование. Ну там сишный ‘fseek’ или плюсовый ‘seekg’.

Так это уже не относится к работе с фс

…и тут в тему врывается поручик Ржевский…

QtCore уже предлагали?

Вопрос по Питону:

— (ТС): Как мне работать с файлами в Питоне?
— Вот функции открыть, закрыть, прочитать.
— (ТС): Спасибо!

Вопрос по C++:

— (ТС): Как мне работать с файлами в C++?
— Вот функция…
— Да ты лох, уже давно есть класс!
— Сам ты лох, я внебрачный сын Страуструпа!
— А я со Страуструпом ходил в один садик!
— (ТС): пацаны, как же всё таки с файлами?
— Иди нах, нам не до тебя!

https://github.com/ned14/llfio

Занятный проект, нужно будет приглядеться. Но на первый взгляд шансов у библиотеки войти в boost или stl нет: слишком мало шаблонной магии, синтаксического сахара и прочей борьбы с ветряными мельницами, всё про реальные проблемы и перформанс.

шансов у библиотеки войти в boost или stl нет

Outcome того же автора уже вошёл. ;)

Необходимость явного вызова fclose после fopen - тоже вполне реальная проблема

А необходимость глушить автомобиль после того как завёл и поездил?

Закрывать за собой квартиру? Закручивать пачку сока?

В мире, в котором мы живём, все так устроено, но почему-то закрыть за собой файл вызывает боль.