• Adam D. Ruppe (18/18) Oct 12 2012 std.stdio has a nice struct called LockingTextReader in the
• Steven Schveighoffer (19/31) Oct 12 2012 What they do is lock the FILE * while you use it, and they are
• Adam D. Ruppe (8/17) Oct 15 2012 I see.

"Adam D. Ruppe" <destructionator gmail.com> writes:

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?

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

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

"Adam D. Ruppe" <destructionator gmail.com> writes:

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.)