14 Dec
2005
14 Dec
'05
8:25 p.m.
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