On Sat, 03 Sep 2011 17:55:12 -0400, Michel Fortin
<[email protected]> wrote:
On 2011-09-03 19:54:05 +0000, Andrei Alexandrescu
<[email protected]> said:
Hello,
There are a number of issues related to D's current handling of
streams, including the existence of the imperfect etc.stream and the
over-specialization of std.stdio.
Steve has worked on an extensive overhaul of std.stdio which would
obviate the need for etc.stream and would improve both the generality
and efficiency of std.stdio.
Please chime in with feedback; he's away from the Usenet but allowed
me to post this on his behalf. I uploaded the docs to
http://erdani.com/d/new-stdio/phobos-prerelease/std_stdio.html
Looks good…
Well, at least someone thinks so ;)
Hum, inconsistent casing of enum members.
Can be fixed.
And shouldn't there be a way to do non-blocking IO? ;-)
Yes. I haven't gotten to that yet. This is a very early version, not
ready for inclusion. It's mostly a proof-of-concept.
I like that File is now a class because it's cleaner that way, but
non-deterministic destruction is going to be a problem. That said, it
was already a problem anyway if you stored a File struct in a class, so
maybe we need a more general solution for reference-counted classes.
I agree, but I think I need to revisit that aspect. As broken as the
reference counting mechanism is, much code is based on it, so we can't say
you have to revisit all source code in order to be compatible.
And as Andrei points out, it works in cases where you *don't* store the
struct on the heap, why should that be disabled?
Class names DInput and DOutput sounds silly. If all classes implemented
purely in D had a D prefix, it'd get redundant pretty fast (like KDE
apps beginning in K).
Yes, it made sense when I was going through the different iterations of my
interface ideas. But you are right. BTW, these started out as
DBufferedInput and DBufferedOutput, and CStream was CBufferedStream.
I'd suggest BufferedInput and BufferedOutput, or something else that
actually describes what the class does, instead of DInput and DOutput.
And I'd make them final, that way there won't be any virtual call
overhead until the buffer needs to be replenished or flushed from the
wrapped input or output stream.
They are final, ddoc just doesn't expose that...
See my later post to the source. Things might be clearer.
-Steve
