std.stream replacement

[Steven Schveighoffer]

On Tue, 05 Mar 2013 11:43:59 -0500, Dmitry Olshansky  
<dmitry.olsh at gmail.com> wrote:


> That's it.
> C's iobuf stuff and locks around (f)getc are one reason for it being  
> slower. In D we need no stinkin' locks as stuff is TLS by default.
>
> Plus as far as I understand your std.io idea it was focused around  
> filling up user-provided buffers directly without obligatory double  
> buffering somewhere inside like C does.

You are right about the locking, though shared streams like stdout will  
need to be locked (this is actually one of the more difficult parts to do,  
and I haven't done it yet.  Shared is a pain to work with, the current  
File struct cheats with casting, I think I will have to do something like  
that).  File does a pretty good job of locking for an entire operation  
(i.e. an entire writeln/readf).

C iobuf I think tries to avoid double buffering for some things (e.g.  
gcc's getline), but std.io takes that to a new level.

With std.io you have SAFE access directly to the buffer.  So instead of  
getline being "read directly into my buffer, or copy into my buffer", it's  
"make sure there is a complete line in the file buffer, then give me a  
slice to it".  What's great about this is, you don't need to hack phobos  
to get buffer access like you need to hack C's stream to get buffer access  
to create something like getline.  So many more possibilities exist.

So things like parsing xml files need no double buffering at all, AND you  
don't even have to provide a buffer!

Note that it is still possible to provide a buffer, in case that is what  
you want to do, and it will only copy any data already in the stream  
buffer.  Everything else is read directly in (I have some heuristics to  
try and prevent tiny reads, so if you want to say read 4 bytes, it will  
first fill the stream buffer, then copy 4 bytes).

-Steve