Комментарии 25
Поэтому в 32-х разрядных приложениях маппинг больших файлов лучше производить через скользящее окно фиксированного размера, а не стараться отобразить весь большой файл в доступное вам пространство.
Для 64-х битных программ ограничение по адресному пространству конечно тоже есть, только оно настолько большое, что можно говорить о бесконечном адресном пространстве.
только оно настолько большое, что можно говорить о бесконечном адресном пространстве.
Вот только у нас есть нюанс в виде расходов на хранение таблицы страниц. На каждую 4-килобайтную страницу приходится по 4 байта метаданных.
Про размер: очень зависит от платформы, многие ОС вообще не предоставляют данный функционал в удобном виде :(
UPD: не важно, только что понял что там стоит size_t значение на кол-во байт, и он обрезает моё 64-х битное значение до 32-х бит при компиляции на x32.
И ни слова про юникод! Ну как так можно?
filesystem::path из Boost и из C++ Standard Library умеют работать с юникодными путями:
boost::filesystem::path my_path(L"Привет мир.txt");
Так что итерирование по директориям, создание/удаление файлов/ссылок работают из коробки.
А вот с чтением файлов дела обстоят похуже:
* std::fstream умеет работать с std::filesystem::path, но не умеет работать с boost::filesystem::path. Если используете Boost версию, придется использовать boost::filesystem::fstream
* boost::interprocess работает только с char*. На POSIX (Linux) это позволяет вам задавать UTF-8 пути, а на Windows — подобное не работает.
На русском он вроде как в ближайшее время не планируется :(
Выбрать PDF покупатели могут на стадии оформления заказа, когда заполняют адрес доставки или выбирают самовывоз со склада в Москве. Ниже есть поле с пометкой о PDF. Он стоит также, как и бумажная версия.
Было бы здорово так же про boost asio и корутины подобные статьи увидеть.
На сайте ozon — самая доступная цена, с учётом скорости доставки по России. ДМК почтой рассылает.
А как на счёт обработки ошибок? Я как то год назад написал кастомный стрим на mmap, а потом на ревью был справедливо закидан помидорами(ссылками на майллисты и статьи) где куча людей обоснованно доносили, что как только у вас есть две и более библиотеки(в одном процессе) которые что то mmapят и подходят к этому ответственно с обработкой ошибок, то у вас не просто УБ, а отдельный котел в аду под названием глобальный обработчик сигналов, который впринципе "правильно" не приготовить. Я к тому что ммап можно использовать безопасно, но только когда есть только одна библиотека, а это почти наверняка не вариант для большого проекта с длинной историей и который использует сразу много больших библиотек. Например культю и буст и тогда готовьтесь к увлекательному дебагу. Ну и как обычно в таких статьях описан самый простой хэпи пас, но хотя бы самую простую ситуацию разберите — читаете из замапленного файла с усб диска, а пользователь, вопреки всем сообщениям ОС, сука такая взял и выдернул флеху и что будет при использовании этой либы? Вариант чуть посложнее — как добавить данные в конец файла? А что если свободного места вдруг не стало, ну например другой процесс записал что то на диск. Тут же все ленивое и преподносится типа как безусловно лучше чем не ленивое. В общем мне как написавшему свой полностью работоспособный стрим и юнит тесты и все такое, а потом выкинувшему все к хренам по причине невозможности правильной работы с ошибками очевидно что статья — не зачёт, даже 10% всей мякотки не раскрывает.
В контексте "самый быстрый" стоит упомянуть O_DIRECT, без которого не всегда получается раскрыть потенциал современных носителей информации. Хотя по подводным камням тут ситуация не сильно лучше чем у mmap.
Работа с файлами в C++ с использованием Boost