Turbo C++ 3.0 bugs

[Chuck Guzis]

On 12/14/2005 at 2:45 PM 9000 VAX wrote:

>
>No, The order is not important. But I have a clue now. It might be
>that Watcom C treats printf() function differently from other
>functions. I think the compiler tends to delay the execution of
>printf(), given that variables to be printed have not yet updated by
>the program. But this trick (to execute printf() with other printf()'s
>for speed?) does not work well if the program needs to read hardware
>inside of printf(). I actually observed the "delayed printf()"
>phenomenon and its effect here is my guess.

Well, printf() does write to a buffered stream, doesn't it, so it will be
delayed unless you also issue a fflush(stdout) immediately thereafter.

When I'm debugging my own code, I use my own unbuffered printf(); it's
smaller, faster and doesn't require that I include all of the stdio streams
library if I don't need it otherwise.  I believe that MS C provides a
similar facility with _cprintf().

Cheers,
Chuck