Есть вот такой код

std::ifstream t("file.txt");
std::string str((std::istreambuf_iterator<char>(t)),
std::istreambuf_iterator<char>());

который приводится в книгах в том числе и классиков, и который должен считывать весь файл в строку полностью.

Вопрос: как в таком случае лучше всего проверять ошибки ввода-вывода? Речь не идёт о ситуации порождения исключения. Вполне возможна ситуация, когда скачался кусок файла из-за недостаточной производительности подсистемы ввода-вывода (для усиления - пусть это будет дискета). В "обычной ситуации" "недосчитывание" можно посмостреть чере fail-bit. Кто как поступает?

Не совсем :) Это скорее сишный код. Точно не STL :)
И отлов ошибок (прочитал меньше, чем должен был) просто переносится в цикл - на вызов fread :))

MasterZiv,
да ни кто в общем-то не мешает. Что-то вроде
t.fail()

Просто при чтении "по привычке" в С-стиле посимвольно всегда можно повторить чтение (в одном и том же цикле). А здесь придётся как-то дочитывать и делать append(). Вот и интересно, кто как заморачивается, если заморачивается.

MasterZiv,
эта конструкция должна читать весь файл в строку, но не гарантирует этого.

Приведу простой (невыдуманный) пример:

Требовалось распарсить ней достаточно большой файл. Читался он в С-стиле с помощью fopen-fclose-fread посимвольно. Проблема была в том, что в таком стиле он парсился достаточно долго. Для ускорения этого процесса сначала стали заводить локальный буфер, в который читался сразу блок, а затем анализ проводился посимвольно (с подкачкой данных в буфер, если финальный токен не оказывался в буфере). Но поддерживать буфер самому посчитали некомильфо, тем более, в потоки ввода-вывода уже встроена буферизация. Решили попробовать "буферизацию от профи", и делали "в лоб" типа while(cin >> ch){}. Такой подход принёс неожиданный сюрприз: хоть "всё и ускорилось", часть файлов, находившихся на NFS или при интенсивной I/O, новой версией парситься перестало. Получалось: когда обработка опустошала буфер cin, если до следующего чтения из cin он не успевал "пополниться", происходил выход из цикла (с флагом cin.fail() ). В результате решили читать не посимвольно, а в string (кусками, чтобы не пытаться запихнуть в память несколько гигов). Опустошить буфер при этом стало проблематично ( мы сделали это в нескольких специальных случаях :), но и на эту "экзотику" ввели проверку и несколько попыток на "дочитывание" (и последующее str.append(rest)). В результате получили 1. выигрыш по скорости по сравнению с небуферизированным чтением 2. уход от ручного управления буферами. По скорости, что интересно, получилось чуть медленнее чистого С с "ручным" буфером.

ЗЫ
Понятно, что можно было написать свой класс, который прятал бы исходный С-буфер и процесс его подкачки. Но решение cin + string оказалось достаточно простым и прозрачным.

ЗЗЫ
Синхронизацию потоков с stdin и stdout отключили сразу, так что из-за этого тормозить не может

White OwlВот что религия с людьми делает.
Нормальный человек возьмет и сделает задачу на том, на чем удобно.
А фанатик stl'я будет упрямо ковырять stl.

Да при чём тут религия? Было старое решение, которое перестало устраивать. Добавили буфер - оказалось, быстро, но неудобно (усложнилась логика работы и стали вылезать косяки по работе с ним у некоторых более неопытных товарищей). Переделали на потоки. Стало просто и квадратно. Можно было, конечно, написать класс-обёртку над "старыми буферами" (чтобы прятать подкачку и буферизацию). Можно такую же обёртку над потоками (чтобы спрятать "дочитывание" при опустошении, но это всего строчка-другая кода). Но зачем, если и так работает? (у них вроде и сейчас так работает)

Dima TBagaBagaНо поддерживать буфер самому посчитали некомильфо
отображение в память средствами ОС не пробовали?

Нет, не пробовали. Тогда нужна была кроссплатформенность (как минимум - на клиенте винда, на сервере - FreeBSD, тогда вроде бы ещё 4.4).