我正在使用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行为直接输出到屏幕，而不是重定向到文件。
答案 0 :(得分：2)
使用nohup运行有很多效果，但主要的是stdin，stdout将被重定向到/ dev / null。在大多数情况下，这意味着stdout将被完全缓冲而不是行缓冲（如果stdout是终端，它的唯一行缓冲），因此输出的东西通常在你进行显式刷新之前不会实际输出。
修改
进一步的更新使问题不太可能与nohup的不同行为直接相关。此时，我建议使用valgrind运行，因为最可能的怀疑是未初始化的局部变量或堆对象。这样的变量将具有不可预测的（但通常是可重复的）值，这取决于调用函数的环境 - 主要取决于先前调用的函数在堆栈上留下的内容，这可能很大程度上依赖于nohup，因为您正在看到< / p>
答案 1 :(得分：0)
您是否在此应用程序中使用线程？
我在Linux上使用/不使用nohup的情况下，在一个性能不佳的线程应用程序中看到了微妙的不同行为，尽管我不知道这是否会用cygwin重现。
在我的情况下，我有两个初始化线程，但它们完成的顺序（错误地）很重要。如果没有'nohup'，总会首先完成，但是对于其他人通常会使用'nohup'，我认为其根本原因是IO缓冲的差异。