Почему стандартные файловые потоки С++ не соответствуют соглашениям RAII более точно?

Хотя другие ответы верны и полезны, я думаю, что настоящая причина проще.

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

Кроме того, ваш вопрос действительно имеет отношение только к файловым потокам, другие типы стандартных потоков не имеют функций-членов open() или close(), поэтому их конструкторы не выбрасывают, если файл не может быть открыт :-)

Для файлов вы можете проверить успешность вызова close(), чтобы знать, были ли данные записаны на диск, так что это веская причина не делать это в деструкторе, потому что к тому времени, когда объект уничтожен, уже слишком поздно делать с ним что-либо полезное, и вы почти наверняка не захотите генерировать исключение из деструктора. Таким образом, fstreambuf вызовет close в своем деструкторе, но вы также можете сделать это вручную перед уничтожением, если хотите.

В любом случае, я не согласен с тем, что это не соответствует соглашениям RAII...

Почему разработчики библиотеки предпочли свой подход открытию только в конструкторах, которые вызывают ошибку?

Н.Б. RAII не означает, что вы не можете иметь отдельный элемент open() в дополнение к конструктору, получающему ресурсы, или вы не можете очистить ресурс перед уничтожением, например. unique_ptr есть reset() член.

Кроме того, RAII не означает, что вы должны создавать ошибки при сбое или объект не может находиться в пустом состоянии, например. unique_ptr может быть создан с нулевым указателем или создан по умолчанию, и поэтому также может ни на что не указывать, поэтому в некоторых случаях вам нужно проверить его перед разыменованием.

Файловые потоки получают ресурс при построении и освобождают его при уничтожении — это, насколько я понимаю, RAII. То, против чего вы возражаете, требует проверки, что пахнет двухэтапной инициализацией, и я согласен, что это немного вонюче. Однако это не делает его не RAII.

В прошлом я решал эту проблему с помощью класса CheckedFstream, который представляет собой простую оболочку, добавляющую единственную функцию: добавление коснтруктора, если поток не может быть открыт. В С++ 11 это так же просто:

struct CheckedFstream : std::fstream
{
  CheckedFstream() = default;

  CheckedFstream(std::string const& path, std::ios::openmode m = std::ios::in|std::ios::out)
  : fstream(path, m)
  { if (!is_open()) throw std::ios::failure("Could not open " + path); }
};

Таким образом, вы получите больше и не меньше.

• Вы получаете то же самое: вы по-прежнему можете открыть файл с помощью конструктора. Вы по-прежнему получаете RAII: он автоматически закроет файл при уничтожении объекта.

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

• Вы получаете не меньше: преимущество, которое вы видите, не является реальным. Вы говорите, что по-вашему не надо проверять при каждой операции. Это неверно. Поток может выйти из строя в любой момент, даже если он успешно открылся (файл).

Что касается проверки ошибок и создания исключений, см. @PiotrS answer. Концептуально я не вижу разницы между необходимостью проверять статус возврата и необходимостью отлавливать ошибку. Ошибка все еще существует; разница в том, как вы это обнаружите. Но, как указывает @PiotrS, вы можете выбрать оба варианта.

Дизайнеры библиотеки дали вам альтернативу:

std::ifstream file{};
file.exceptions(std::ifstream::failbit | std::ifstream::badbit);

try
{
    file.open(path); // now it will throw on failure
}
catch (const std::ifstream::failure& e)
{
}

Файловые потоки стандартной библиотеки делают обеспечивают RAII в том смысле, что вызов деструктора для одного из них закроет любой файл, который окажется открытым. По крайней мере, в случае вывода, однако, это экстренная мера, которую следует использовать только в том случае, если вы столкнулись с другой ошибкой, и не собираетесь использовать записываемый файл в любом случае. (Хорошей практикой программирования было бы удалить его.) Как правило, вам нужно проверить состояние потока после его закрытия, и это операция, которая может завершиться ошибкой, поэтому не следует делается в деструкторе.

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

Что касается open: вы можете так же легко открыть в конструкторе, и для изолированного использования, как вы показываете, это, вероятно, предпочтительное решение. Но бывают случаи, когда вы можете захотеть повторно использовать std::filebuf, явно открывая и закрывая его, и, конечно, почти во всех случаях вы захотите обработать сбой при открытии файла немедленно, а не через какое-то исключение.

Это зависит от того, что вы делаете, читаете или пишете. Вы можете инкапсулировать входной поток способом RAII, но это не так для выходных потоков. Если целью является файл на диске или сетевой сокет, НИКОГДА, НИКОГДА не помещайте fclose/close в деструктор. Потому что вам нужно проверить возвращаемое значение fclose, и нет возможности сообщить об ошибке, произошедшей в деструкторе. см. Как мне обработать деструктор, который не работает