On 12/23/19 10:25 AM, H. S. Teoh wrote:
On Sun, Dec 22, 2019 at 10:04:20PM +0000, Adam D. Ruppe via Digitalmars-d-learn
wrote:
[...]
Regardless, I'm pretty well of the opinion that fwrite is the wrong
thing to do anyway. fwrite writes bytes to a file, but we want to
write strings to the console. There's other functions that do that.
[...]
Would it make sense for std.stdio.write* (the package global functions,
as opposed to File.write*) to use the Windows console output functions
instead of proxying to libc?
That means we have to buffer separately, which means we have a problem
interleaving printf with writef. It would be awful.
Alternatively, we could change std.stdio.File to check if the current
file descriptor is the console (fd == stdout && stdout == console,
however you figure that out in Windows), and silently switch to the
Windows console output functions instead of libc. We *are* already
wrapping libc's FILE*, why not wrap the Windows console output functions
as well.
Again, the docs say you have to use wprintf, not fwrite. We would have
to switch to using wprintf, and I'm not sure it's very easy thing to do.
It might be possible though.
Mixing raw libc printf with std.stdio.write* is a bad idea anyway; do we
really need to support that?? Though calling fflush(stdout) may not be
amiss, just to alleviate sudden breakage and ensuing complaints.
There's this guy, his name is Walter. He likes printf. I'm pretty sure
when he's buried, his cold dead fingers will be tightly and inextricably
wrapped around printf.
And of course, this only applies to Windows. On Posix libc is pretty
much still the standard way of working with console output.
The source of this thread is for valid unicode to come out on the
screen, which I'm pretty sure Posix systems support just fine.
Other than that, there are good reasons NOT to use libc, but this is
disruptive and difficult to get right as a "drop in"
-Steve
