Файловые потоки и причины ошибок

Но с какой стати, если стандартная библиотека С++ не обязана ничего знать о существовании errno?

С чего бы? В стандартную библиотеку C++ входит и стандартная библиотека C. Для удобства их ещё и в std:: запихали, и C++-хедеры приделали: https://en.cppreference.com/w/cpp/header/cerrno

Из этого абсолютно не следует, что iostream должен как-то с errno взаимодействовать.

Возможно, что в тексте исключений что-то будет, только их надо включить. А с C++11 std::ios_base::failure наследуется от system_error, там может быть больше информации.

Как грамотно различать ошибки при работе с файловыми потоками (std::ofstream)?

Ловить std::ios_base::failure.

27.5.3.3.1 параграф 2:

When throwing ios_base::failure exceptions, implementations should provide values of ec that identify the specific reason for the failure. [ Note: Errors arising from the operating system would typically be reported as system_category() errors with an error value of the error number reported by the operating system. Errors arising from within the stream library would typically be reported as error_code(io_errc::stream, iostream_category()). — end note ]

По стандарту не обязана.

Но существующие реализации вызывают код libc, поэтому errno выставляется, если ошибка происходит в libc.

можно не выпендриваться и юзать сишные функции

Это да, я указывал на некорректность конкретного суждения

Звучит интересно, но почему-то пример с: https://en.cppreference.com/w/cpp/io/ios_base/failure

выдает только малоинформативное «iostream error», а код всегда 1.

27.5.3.3.1 параграф 2:

Ты наверное имел ввиду 27.5.3.1.1 Class ios_base::failure.

Да, верно.

Значит, «implementation does not provide» (:

Причем, ни gcc ни clang «does not provide». На сколько я понял, boost::filesystem::ofstream тоже ничего в плане ошибок не дает по сравнению с std::basic_ofstream, чисто обертка для интеграции с boost::filesystem::path.

boost::filesystem::ofstream тоже ничего в плане ошибок не дает

Подтверждаю: не дает. Специально проверил.
Возможно Boost Iostreams умеет определять ошибки, но я не пробовал. Так или иначе, пожалуй проще и быстрее использовать (хоть это и не по c++-ному):

cerr << strerror(errno) << endl;

Публичные функции boost::filesystem заполняют boost::error_code, в котором содержится код ошибки от операционки (на Windows достается из ::GetLastError, на POSIX errno). Перегрузки не выбрасывающие исключения пишут его в параметр, переданный по ссылке. Перегрузки выбрасывающие исключения вкладывают его в само исключение.

А вот boost::filesystem::fstream действительно простейшая обертка над std::fstream. Тут уже подробности (от ОС) о том, что за ошибка произошла клиентскому коду явно не транслируют.

failure содержит errno если это произошло на операции чтения
во всех остальных случаях оно не нужно

Как это в 'остальных не нужно'? А файл не найден, недостаточно прав и др.?

вы слишком хотите от иострим потоков
для того что вы говорите сделали std:filesystem
как помню в комитете обсуждали вообще оистрим сделать депрекейтед и удалить

кстати да, посмотрел, оно платформик специфик оказалось
но в целом за десятки лет использования для вывода и ввода с файлов
не припомню что бы в errno была необходимость

27.5.3.1.1

Такого вообще нет, а 27.5.3.3.1 это «move_iterator constructors [move.iter.op.const]»

Есть. Ты где смотришь? Возможно мы смотрим разные версии черновиков. Я смотрю c++11.

Ты где смотришь?

В действующей версии стандарта, где же ещё?

Разве это много? Особенно учитывая то, что в errno это давно имеется.

Действующая это какая?

https://www.iso.org/standard/68564.html

Ты не понял видимо. Действующий это какой? 11, 14, 17 ? Они все действующие. Правильнее выражаться «последний» :-)

Это ты не понял, видимо. Статус у 11-го и 14-го — Withdrawn.

мы смотрим разные версии

Они все действующие.

Withdrawn — это «действующий»?

Это не мешает их использовать.

Это не означает, что они не действуют. Пожалуйста бери используй.

А что Withdrawn переводится как НЕ ДЕЙСТВУЮЩИЙ?

Госприёмка пропустит продукт сделанный с использованием отозванного стандарта?

А как отозванное может действовать?

Гугл переводит это слово «Изъятый». Госприемка - это не самый лучший показатель.

Как это в 'остальных не нужно'? А файл не найден, недостаточно прав и др.?

Для логики приложения не часто нужно. А вот лог конкретную ошибку записать было бы полезно. Вариант при неудачи ручками выдернуть из errno/::GetLastError. Но это не очень надежно, нет гарантии, что в этом же треде потом не было обращения к API операцинки. Implementation defined получается.