Файлы и потоки в C++: рабочие приёмы из практики

Задача звучит просто: прочитать текстовый файл и что-то с ним сделать. Наивная реализация через while (std::getline(...)) работает на тестовом файле в 10 килобайт и падает по времени на продовом логе в 3 гигабайта. Разберём, где именно теряется производительность при работе с файловыми потоками в C++ и как это чинится без перехода на C и сырые дескрипторы. Код проверялся на GCC 13 и Clang 17, стандарт C++17 (кое-где отмечено, что появилось в C++20).

Почему очевидное чтение медленное

Стандартный подход выглядит так:

#include <fstream>
#include <string>

std::ifstream file("app.log");
std::string line;
while (std::getline(file, line)) {
    // обработка строки
}

Проблем здесь несколько, и они складываются. Во-первых, std::ifstream по умолчанию синхронизирован с C-потоками через std::ios::sync_with_stdio — на чтении это лишняя прослойка. Во-вторых, каждый getline копирует данные в std::string, и на миллионах коротких строк аллокатор работает больше, чем диск. В-третьих, поток открыт в текстовом режиме, а не бинарном, и на некоторых платформах занимается преобразованием переводов строк.

Что даёт отключение синхронизации

Если вы не смешиваете std::cin/std::cout с printf/scanf, синхронизацию можно снять. Это ускоряет потоковый ввод-вывод, потому что убирается двойная буферизация между iostream и stdio.

#include <iostream>

int main() {
    // Снимаем синхронизацию до первой операции ввода-вывода
    std::ios::sync_with_stdio(false);
    // Отвязываем cin от cout, чтобы cout не флашился перед каждым чтением
    std::cin.tie(nullptr);
    // дальше обычная работа с cin/cout
}

Вызывать sync_with_stdio(false) нужно до первого чтения или записи, иначе поведение не определено в части уже накопленных буферов. И держите в голове: после этого смешивать iostream и stdio в одной программе нельзя.

Проверка состояния потока — не опционально

Самая частая ошибка в коде на ревью: открыли файл и сразу читаете, не проверив, открылся ли он. Если файла нет или нет прав, ifstream не бросит исключение по умолчанию — он просто перейдёт в состояние fail, и цикл чтения ни разу не выполнится. Программа отработает "успешно" на пустых данных.

std::ifstream file("config.json");
if (!file) {                 // проверяем сразу после открытия
    // здесь file.is_open() == false
    return handleOpenError();
}

У потока четыре бита состояния, и путать их — источник тонких багов:

• good() — всё в порядке, можно продолжать;
• eof() — достигнут конец файла (взводится после попытки чтения за границей, а не по достижении последнего байта);
• fail() — логическая ошибка: не удалось распарсить, не открылся файл, неверный формат;
• bad() — фатальная ошибка потока, обычно уровня операционной системы.

Классическая ловушка — цикл while (!file.eof()). Он читает последнюю строку дважды или обрабатывает мусор, потому что eof() становится истинным только после неудачного чтения. Правильный цикл проверяет результат самой операции: while (std::getline(file, line)) или while (file >> value) — оба возвращают ссылку на поток, которая приводится к bool.

Поток не сообщает об ошибке открытия исключением, пока вы его об этом не попросили. По умолчанию он молча ставит fail-бит — и молча читает ноль строк.

Когда хочется исключений

Если проверять биты вручную на каждом шаге лень и хочется единой точки обработки, включите исключения через exceptions():

std::ifstream file;
// Просим бросать исключение при fail и bad, но НЕ при eof —
// иначе нормальное завершение чтения станет исключением
file.exceptions(std::ifstream::failbit | std::ifstream::badbit);
try {
    file.open("data.bin", std::ios::binary);
    // ... чтение
} catch (const std::ios_base::failure& e) {
    // e.what() и e.code() дадут детали
}

Осторожно: если добавить в маску eofbit, то штатное окончание файла тоже полетит исключением, и цикл чтения превратится в перехват исключения на каждом файле. Обычно взводят только failbit | badbit.

Быстрое чтение файла целиком

Когда файл нужен весь и помещается в память, читать его построчно бессмысленно. Быстрее прочитать одним блоком. Надёжный приём — узнать размер через позиционирование и прочитать в буфер:

#include <fstream>
#include <string>
#include <stdexcept>

std::string readWholeFile(const std::string& path) {
    std::ifstream file(path, std::ios::binary | std::ios::ate);
    if (!file)
        throw std::runtime_error("cannot open " + path);
    // ate поставил позицию в конец — узнаём размер
    const std::streamsize size = file.tellg();
    std::string buffer(static_cast<size_t>(size), '\0');
    file.seekg(0, std::ios::beg);        // возвращаемся в начало
    file.read(buffer.data(), size);      // читаем одним вызовом
    if (file.gcount() != size)
        throw std::runtime_error("short read");
    return buffer;
}

Метод read не завершает буфер нулём и не проверяет за вас, сколько прочитано, — для этого есть gcount(). Открывайте в режиме binary, иначе на Windows размер, посчитанный через tellg, разойдётся с числом реально прочитанных байт из-за преобразования переводов строк.

Три способа читать большой файл — с ценой каждого

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

mmap — это системный вызов POSIX, а не часть стандартной библиотеки; на Windows аналог — CreateFileMapping/MapViewOfFile. Он даёт файл как область памяти, но приносит платформозависимость и класс ошибок вроде SIGBUS при усечении файла другим процессом во время маппинга. Берите его, только когда профилировщик показал, что упираетесь именно в чтение, а не в свою обработку.

Если читаете блоками — не забудьте про хвост

Типичная ошибка при чтении фиксированными блоками: последний блок обычно короче. Полагаться на то, что read заполнит весь буфер, нельзя — всегда смотрите gcount():

char buffer[64 * 1024];
while (file.read(buffer, sizeof(buffer)) || file.gcount() > 0) {
    // gcount() — сколько реально прочитано в этот раз,
    // на последней итерации меньше sizeof(buffer)
    process(buffer, file.gcount());
}

Условие file.read(...) || file.gcount() > 0 нужно именно из-за хвоста: когда прочитан неполный блок, read вернёт поток в состоянии fail (не набрал запрошенный объём), но gcount() покажет, что часть данных всё же есть.

Запись: буферизация и когда данные реально на диске

Ещё одно место, где ломаются ожидания. Вызов file << data не пишет на диск немедленно — данные лежат в буфере потока. Они уходят в ОС при заполнении буфера, при закрытии файла или при явном flush(). Отдельная ловушка — std::endl: он не просто вставляет перевод строки, а ещё и делает flush. В цикле на миллион строк это миллион флашей и заметная просадка. Используйте '\n', а флашьте осознанно.

И даже flush() не гарантирует, что данные физически на диске — он лишь отдаёт их операционной системе. Для настоящей долговечности (базы, критичные логи) нужен системный fsync на дескрипторе, а его из ofstream напрямую не получить — придётся работать с open/write/fsync или платформенным API.

Работа с путями: std::filesystem вместо строк

С C++17 склеивать пути строками через + "/" + не нужно — есть std::filesystem::path, который знает про разделители платформы:

#include <filesystem>
namespace fs = std::filesystem;

fs::path dir = "/var/log/myapp";
fs::path full = dir / "today.log";   // оператор / собирает путь корректно
if (fs::exists(full) && fs::file_size(full) > 0) {
    // файл есть и не пустой
}

Функции с исключениями (fs::file_size) имеют перегрузки с std::error_code — на горячих путях, где исключение дорого, берите вариант с кодом ошибки. Проверять exists перед открытием — это гонка (файл могут удалить между проверкой и открытием), поэтому в критичном коде правильнее просто пытаться открыть и обрабатывать ошибку.

Что делать дальше

Если работаете с текстом, который надо парсить, — посмотрите в сторону std::string_view для нарезки уже прочитанного буфера без копирования; это отдельная большая тема. Если упираетесь в скорость — сначала профилировщик (perf, valgrind --tool=callgrind), потом mmap, а не наоборот. Настройте размер буфера потока через rdbuf()->pubsetbuf до открытия, если по замерам стандартных 8 КБ мало. И заведите привычку проверять состояние потока сразу после открытия — это ловит больше багов, чем любая оптимизация.