Может ли перенаправление вывода экрана в файл изменить результат кода C ++?

Question

У меня очень странное поведение с кодом C ++: он дает разные результаты при работе с перенаправлением вывода экрана в файл и без него (воспроизводится в cygwin и linux). Я имею в виду, что если я получу такой же исполняемый файл и запустлю его как ./run или запусту как ./run >out.log, я получу другие результаты!

Я использую std :: cout для вывода на экран, все строки заканчиваются на endl; Я использую ifstream для входного файла; Я использую ofstream для вывода, все строки заканчиваются на endl.

Я использую g ++ 4.

Есть идеи, что происходит?

ОБНОВЛЕНИЕ: Я жестко закодировал входные данные, поэтому «ifstream» не используется, и проблема не устранена.

ОБНОВЛЕНИЕ 2: Это становится интересным. Я проверил три переменные, которые вычисляются изначально, и это то, что я получаю при использовании с и без перенаправления вывода в файл

redirected to file: 0 -0.02 0

direct to screen: 0 -0.02 1.04083e-17

Таким образом, существует разница округления в переменных кода с перенаправлением вывода и без него!

Теперь, почему перенаправление мешало бы внутреннему вычислению кода?

ОБНОВЛЕНИЕ 3: если я перенаправляю в / dev / null, я получаю поведение sam как вывод непосредственно на экран вместо перенаправления в файл.

Answer 1

Есть несколько эффектов запуска с nohup, но основным из них является stdin, и stdout будет перенаправлен в / dev / null. В большинстве случаев это означает, что stdout будет полностью буферизован вместо буферизации строки (это единственная буферизованная строка, если stdout является терминалом), поэтому выводимые данные обычно не будут выводиться до тех пор, пока вы не выполните явный сброс.

Редактировать

Дальнейшие обновления делают маловероятным, что проблема напрямую связана с другим поведением nohup. На этом этапе я бы предложил запустить с valgrind , поскольку наиболее вероятным подозрением является неинициализированная локальная переменная или объект кучи. Такая переменная будет иметь непредсказуемое (но, как правило, повторяемое) значение, которое зависит от среды, в которой была вызвана функция, - в основном от того, что ранее были вызваны функциями в стеке, что вполне может зависеть от nohup, как вы видите

Answer 2

Используете ли вы темы в этом приложении?

Я видел немного другое поведение плохо синхронизированного многопоточного приложения в Linux с / без nohup, хотя я не знаю, было ли это воспроизведено с помощью cygwin.

В моем случае у меня было два потока инициализации, но порядок, в котором они заканчивались, был (по ошибке) значительным. Без 'nohup' один всегда выполнялся бы первым, но с 'nohup', как правило, выполнялся бы другой, я думаю, что основной причиной были различия в буферизации ввода-вывода.