On Tue, 05 Mar 2013 11:43:59 -0500, Dmitry Olshansky
<dmitry.o...@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
