std.stdio has a nice struct called LockingTextReader in the source. The thing is it isn't documented at all, and I don't think it even does its own interface.

It claims to return dchars, but apparently reads bytes.

Its counterpart, LockingTextWriter, seems to do a little more dchar related stuff but again, I'm not sure what exactly it is supposed to do.



What are these supposed to actually do? I tried doing a simple unix cat like program:

stdout.write(LockingTextReader(File("in"));

and while it worked correctly on an ascii text file, it corrupted a binary file. The name "Text" makes me think it isn't meant to work on a binary file, but it'd be so useful if it did...

and besides, if it assumes utf8, why didn't it throw an invalid text exception when fed the binary data?


So, my question is: what are these supposed to do? I'd really like to have byChar and byByte equivalents and this comes close but not quite. Bug?

On Fri, 12 Oct 2012 13:06:16 -0400, Adam D. Ruppe <destructionator@gmail.com> wrote:

> std.stdio has a nice struct called LockingTextReader in the source. The thing is it isn't documented at all, and I don't think it even does its own interface.
>
> It claims to return dchars, but apparently reads bytes.
>
> Its counterpart, LockingTextWriter, seems to do a little more dchar related stuff but again, I'm not sure what exactly it is supposed to do.

What they do is lock the FILE * while you use it, and they are input/output ranges.  So instead of acquiring a lock every time you call fwrite/fprintf, it locks once, and calls a special version of these that assumes the object is already locked.  This speeds up output tremendously, but still isn't as good as it could be with native D code.

From what I remember, the non-UTF8 mode depends on C wide char support, which is severely lacking, and doesn't even work right on some platforms.

> What are these supposed to actually do? I tried doing a simple unix cat like program:
>
> stdout.write(LockingTextReader(File("in"));
>
> and while it worked correctly on an ascii text file, it corrupted a binary file. The name "Text" makes me think it isn't meant to work on a binary file, but it'd be so useful if it did...

What platform?  On Windows, there is the whole issue of CRLF -> LF translation.

In my update to stdio (long overdue), I have support for reading/writing 5 forms of UTF -- UTF8, UTF16, UTF16LE, UTF32, UTF32LE, along with binary read/write support using native D buffers, and avoiding locking altogether if your object isn't shared.

Note that C has very poor support for anything other than ASCII.  For instance, fwide on Windows is a noop (not DMC, but windows), and doesn't work correctly from what I tested on Linux.

-Steve

On Friday, 12 October 2012 at 17:48:40 UTC, Steven Schveighoffer wrote:
> This speeds up output tremendously, but still isn't as good as it could be with native D code.

I see.


> What platform?  On Windows, there is the whole issue of CRLF -> LF translation.

I tried it on Linux. CRLF was my first thought too, but I didn't look too much into it since I wasn't sure if was was supposed to work with binary files at all!

> In my update to stdio (long overdue), I have support for reading/writing 5 forms of UTF -- UTF8, UTF16, UTF16LE, UTF32, UTF32LE, along with binary read/write support using native D buffers, and avoiding locking altogether if your object isn't shared.

Yeah, that might be good. (I worry about breaking existing code, but meh, that's a separate issue.)