Насколько я понимаю, write() - это системный вызов, который очень медленный. (Это почти как межпроцессное взаимодействие.) Все, что работает с FILE, буферизуется и выполняет системный вызов каждые 512 байт или что у вас есть. Таким образом, по скорости FILE должно быть намного быстрее.
Но если у вас есть сообщение журнала, за которым следует что-то, вызывающее coredump, я не знаю механизма, с помощью которого ОС могла бы выкопать FILE буфера и напиши на диск. Таким образом, вы можете легко пропустить последние 5-10 строк вашего файла журнала. Для такого программного обеспечения, как финансовое программное обеспечение, где ошибки могут буквально стоить миллиарды, а вы не хотите, чтобы их было дважды, и, следовательно, нуждаетесь в отличной регистрации, это было бы плохо.
По крайней мере, так было 25 лет назад. ,Мне интересно, изменились ли вещи в эти дни? Например, существует ли механизм, посредством которого ОС сообщают стандартным библиотекам C о необходимости сбрасывать выходные буферы даже после SEGV или чего-то еще? Если так, то FILE внезапно выглядит намного лучше: скорость без надежности. Plauger в своей книге 1992 года о Standard C Library упомянул, что в теории write () также может быть некоторой буферизированной функцией вместо системного вызова.
Часть вопроса: есть ли какие-нибудь варианты компиляции наWindows или Linux, которые влияют на этот компромисс? Не просто, скажем, -O2, а опции, которые фактически влияют на очистку буфера при дампе ядра?
Это не теоретический вопрос о том, что разрешено, а скорее практический вопрос о сегодняшних и будущих Linux и Windows. Хотя я знаю, что различные рассматриваемые стандарты обещают тот или иной уровень надежности или производительности, часто они ослаблены до такой степени, что они бесполезны, поскольку они пытаются охватить такие редкие ситуации, как интерпретатор C или код, работающий на Cray 80-х,или что-то. Кроме того, хотя я могу (и проверяю) это сам, мой вопрос немного шире, чем то, что дает мне современное программное обеспечение с параметрами компиляции по умолчанию.