Если это запись в лог - очень даже критично. Процесс повис/рухнул/сняли и ты не в курсе что последнее сделала прога, т.к. буфер умер вместе с процессом.
Даже если не умер - смотришь параллельно лог - действие реально сделано, а в логе не видно, т.к. на диск еще не сбросилось.

ИМХУ flush() после каждой записи в лог обязательно должен быть.

gamedev_12.15,

замени endl на "\n" и затести. Будет быстрее.

Если поток закрывается корректно - в итоге все будет на диске.

gamedev_12.15ok,
если не использовать flush() запись в файл будет только закрытии файла и при переполнении CRT буфера.
Тогда во сколько раз время записи на диск полного CRT буфера может отличаться от flush() для строки?(при исп. OS:windows msvc2008)
Какой размер буфера и от чего он зависит - ХЗ.
Какой размер строки - тебе виднее.

Затести:
1. Размер буфера: пиши блоки по килобайту одновременно в консоль пиши размер отправленного в поток, снимай задачу и сравнивай что в консоле и что на диске.
2. Скорость записи: запиши гиг с flush() и без.

Basil A. SidorovВот когда действительно потребуется логирование предсмертных конвульсий - тогда и надо думать, как затормозить работу.
Когда конвульсии начинаются - уже нет времени думать, надо пациента воскрешать.

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

Basil A. SidorovЯ, как бы, несколько лет администрировал систему, где режим отладочных логов был чаще включен, чем выключен.
Была масса ошибок и аварийных ситуаций, включая фатальные, но не разу не возникло вопроса: "А что было за секунду до падения???".
Это проблема того что пишут в логи, а не подхода как писать логи. К разработчику хоть раз обращался?

Лично я пишу в логи самое-самое важное. Мою систему администрируют посторонние админы. Все живет в полном автомате. Чего там у них происходит я понятия не имею. Происходит все: от кривых рук до кривого железа. Если ко мне (разработчику) обращается админ с какой-то проблемой, то первое что я прошу - логи. Фатальные проблемы крайне редки, там где они учащаются - включаем отладку. По итогу разбора какие-то отладочные записи переходят в самое-самое, т.е. пишутся всегда. В итоге в 99% случаев по просмотру лога я всегда ставлю правильный диагноз.

Basil A. Sidorovвполне себе практический опыт.
Вот теперь понятно. Опыт разный т.к. задачи разные. У тебя система с пользователями, у меня автомат, который должен работать нисмотря ни на что. У тебя система упала - тутже пользователи закипишили. У меня упала - никто не заметил, через 1-3 часа юзеры начинают подозревать неладное (не видя моих результатов в своей системе), пинают админа, он быстро реанимирует (если получится, обычно получается) и ко мне - что это было? За что я огреб? Что сделать чтоб этого больше не было? И тут я ему должен убедительно ответить что было. А если он пока реанимировал снимал задачи, ребутил и т.п. то я должен это знать.

Скорость чтения рядового человека 100-200 слов в минуту. Какой смысл писать гигабайты логов если они не смогут быть прочитаны?
Для гигабайтов есть БД, такие логи лучше писать туда с мало-мальской формализацией, чтобы потом фильтровать можно было под 100-200 слов в минуту.

Basil A. SidorovАникейщик это а не админ.
Если человек не вчера начал работать, то о проблемах он должен знать раньше пользователей. Хотя бы для того, чтобы не огребаться. И логи разбирать - прямая его обязанность.
Согласен, только презумпция невиновности в его пользу. Начнись разбор проблемы на уровне начальства - крайний я. Потому что он в штате, а я просто поставщик услуги, обещающий конкретные параметры в договоре.