AutoHotkey Community

FileAppend,Text,* outputs text to standard output (stdout). However, since C++ buffers stdout like any other FILE* by default, it isn't practical for real-time uses such as debugging or inter-process communication. In v1.0.47.06, the following example outputs to stdout only when the script is terminated (or at least very infrequently) rather than the expected once per second:
Excluding user-defined functions, I can see two solutions:

1. Introduce another option to FileAppend, such as ** instead of *, to mean flush stdout after writing.
2. Disable buffering for stdout.

I'd opt for the second option, since the following C++ will work for the lifetime of the application:
However, this may impact performance of scripts that write a lot to stdout (and don't need it in real-time.)

I have missed this functionality also.

Lexikos,

So you think that executing setvbuf(stdout, NULL, _IONBF, 0) unconditionally sometime during program startup is best? I wish it could be known how much it decreases performance; if it's merely due to the higher write frequency (e.g. drive seek times), that wouldn't seem too bad.

This change might also raise the question of whether some option should be provided to do the same for normal files written by FileAppend; otherwise the behavior might seem inconsistent (though it could be documented).

It is the easiest option if buffering is typically not desired for stdout. I mostly used it as a "quick fix" while debugging; any concern of performance didn't seem worth the trouble of implementing another option for FileAppend.

I think it may be difficult to measure the performance of stdout, since it may depend on the application (how stdout is implemented and what happens when the data is read from the other end...)
Since closing the file pointer also flushes its buffers, I think buffering could only be an issue for FileAppend in its one-parameter mode within a file-reading loop. The need for an external application to read from the file while the loop is running would probably be very rare.

That seems reasonable. I've added it to WinMain():
setvbuf(stdout, NULL, _IONBF, 0);

The source code for setvbuf() looks small and fast, so it shouldn't affect size or performance too much.

Thanks.