Исправление EXL, (текущая версия) :
Но видимо и тебе и futuram-е известно нечто большее, можете здесь об этом рассказать (я не стебусь если что).
Так я тут как раз и рассказал то, что знаю и считаю важным:
stdout является буферизированным потоком, поэтому при некоторых обстоятельствах, таких как вывод чего-либо в быстром цикле и т. д. – сообщения могут запаздывать или сбрасываться внутрь консоли лишь после закрытия программы или после выхода из функций и пр. С этим связано много проблем при отладочном выводе printf()’ами в различных окружениях. Потому опытные программисты всегда выплёвывают отладку в fprintf(stderr, ...), чтобы избежать этих side-эффектов и сэкономить кучу времени.
stderr не является буферизированным потоком, поэтому вывод каких-либо сообщений в stderr моментально выведет их на консоль, даже в ущерб той производительности, которая обеспечивается буфером.
В популярных UNIX-like консольных программах, в т. ч. и входящих в Base System разных Linux-дистрибутивов нет чёткой градации и стандартов, когда использовать stderr, а когда – stdout, все делают так как того пожелают.
К примеру, я не понимаю почему GCC по gcc -v выплёвывает версию в stderr, вместо более логичного для этого stdout и пр. подобные примеры.
$ gcc -v | grep unknown
# Вывод в stderr.
# Хрен тебе! Ковыряйся с пайпами, вспоминай `1>&2` или `2>&1` или ещё как.
$ ld -v | grep unknown
# Вывод в stdout.
# Всё работает как надо.
Исходная версия EXL, :
Но видимо и тебе и futuram-е известно нечто большее, можете здесь об этом рассказать (я не стебусь если что).
Так я тут как раз и рассказал то, что знаю и считаю важным:
stdout является буферизированным потоком, поэтому при некоторых обстоятельствах, таких как вывод чего-либо в быстром цикле и т. д. – сообщения могут запаздывать или сбрасываться внутрь консоли лишь после закрытия программы или после выхода из функций и пр. С этим связано много проблем при отладочном выводе printf()’ами в различных окружениях. Потому опытные программисты всегда выплёвывают отладку в fprintf(stderr, ...), чтобы избежать этих side-эффектов и сэкономить кучу времени.
stderr не является буферизированным потоком, поэтому вывод каких-либо сообщений в stderr моментально выведет их на консоль, даже в ущерб той производительности, которая обеспечивается буфером.
В популярных UNIX-like консольных программах, в т. ч. и входящих в Base System разных Linux-дистрибутивов нет чёткой градации и стандартов, когда использовать stderr, а когда – stdout, все делают так как того пожелают.
К примеру, я не понимаю почему GCC по gcc -v выплёвывает версию в stderr, вместо более логичного для этого stdout и пр. подобные примеры.
$ gcc -v | grep unknown
# А хрен тебе! Ковыряйся с пайпами, вспоминай `1>&2` или `2>&1` или ещё как.
$ ld -v | grep unknown
# Всё работает как надо.