Why Does My Cout Output Not Appear Immediately

std::cout won't print

Make sure you flush the stream. This is required because the output streams are buffered and you have no guarantee over when the buffer will be flushed unless you manually flush it yourself.

std::cout << "Hello" << std::endl;

std::endl will output a newline and flush the stream. Alternatively, std::flush will just do the flush. Flushing can also be done using the stream's member function:

std::cout.flush();

cout does not print even with time delay

std::cout is usually buffered, meaning it may not output immediately unless you force it to. Try std::flush after your first output:

std::cout << "hello " << std::flush;

No console output on cout

You need to end output strings with newline, e.g.: `cout << "test\n"``. The reason is that the standard output is buffered and the buffer is flushed on newline. There probably exists a way to flush the cout buffer without outputting a newline, but I don't know it by heart. Probably includes access to the underlying streambuf (via the rdbuf method).

No output from C++ program

I found the actual problem. I didn't compile the application statically which caused it to rely on dependencies not found in WinPE. I re-compiled it using the '-static' flag and it now works as expected on both WinPE and desktop versions of Windows.

Why the order is not preserved when printing something, first with cerr and then cout?

std::cerr and std::cout are different streams and they are not synchronized.
So you really can't assume anything about how output to both gets shown. In this case, the output happens to be shown before the error.

You can rely on the order within either stream.

Additionally, std::cout is buffered and std::cerr is not, and that often causes this kind of problem, but because you are using std::endl (which flushes the stream) this doesn't really apply in your case.

Cout Not Printing the Return Value from the function

The console simply displays a blank screen.

That is a problem. Not so much because your program crashed, but because you do not know where it crashed. The traditional remedy for this is to use a debugger, but in this case diagnostic output could be illuminating. Furthermore, for a project like this (a fairly simple console program), I would recommend having diagnostic output from the start so that you can verify your code as you go along.

What would be good diagnostic output? The core of PrefixEvaluation() is the stack st, so add a diagnostic line before every push and pop. This diagnostic should show the pieces you are working with. For example, when pushing a digit:

std::cerr << "Push " << s[i] << '\n'; // Not converted to int
st.push(s[i] - '0');

(I use std::cerr because it is unbuffered, and because it is possible to separate cout and cerr output by redirecting one of them to a file.) Next example, when pushing an operation:

std::cerr << "Push " << op1 << " + " << op2 << '\n';
st.push(op1+op2);

Do this for all the operations, plus the two pops, and you should see why your program crashed:

Prefix Evaluation: 
Push 4
Push 7
Push 9
Pop  9
Pop  7
Push 9 * 7
Push 9
Pop  9
Pop  63
Push 9 / 63
Push 9
Pop  9
Pop  0
Push 9 / 0

There you go – you hit a division by zero error. (Note: this is a reason to output the pieces without combining them. If the diagnostic was std::cerr << "Push " << op1/op2 << '\n'; then the diagnostic would unhelpfully crash.) To make your program stable (i.e. work even when the input is bad), you should check for zero before dividing. It's up to you to decide what the program should do in this case. Perhaps you simply want to inform the user and exit.

if ( op2 == 0 ) {
    std::cout << "Division by zero!\n";
    std::exit(1);
}
st.push(op1/op2);

Don't forget to remove (or comment out) the diagnostics before declaring the project done.

---

You could get the same result from a debugger. Let the debugger break execution just as the program crashes, then look at the values of your variables at that point. See that op2 is zero. It works, but if you want to find out why op2 is zero, you often have to do another run, breaking multiple times. In contrast, the diagnostic outputs let you quickly trace the source of the zero to 9/63 with just one run.

The speed of tracing the state of your stack is the reason I find diagnostics helpful in this situation. Each test case can be quickly checked not only for the correct final result, but also for the correct computations along the way. The computations stand out, so if you know which should have been performed, you can scan the output to make sure each is present. This lets you check for many potential bugs with not much effort.

---

Related Topics