07-Jan-2014 11:59, Jason White пишет:
On Monday, 6 January 2014 at 10:26:27 UTC, Dmitry Olshansky wrote:
Ok, now I see. In my eye though serialization completely hides raw
stream write.
So:
struct SomeStream{
void write(const(ubyte)[] data...);
}
struct Serializer(Stream){
void write(T)(T value); //calls stream.write inside of it
private:
Stream stream;
}
I was thinking it should also have "alias stream this;", but maybe
that's not the best thing to do for a serializer.
I concede, I've s/(read|write)Data/\1/g on
https://github.com/jasonwhite/io/blob/master/src/io/file.d
and it now works on Windows with useful exception messages.
Cool, got to steal sysErrorString too! :)
Actually these objects do just fine, since OS does the locking (or
makes sure of something equivalent). If your stream is TLS there is no
need for extra locking at all (no interleaving of I/O calls is
possible) regardless of its kind.
Shared instances would need locking as 2 threads may request some
operation, and as OS locks only on per sys-call basis something cruel
may happen in the code that deals with buffering etc.
Oh yeah, you're right.
As a side note: I would love to get a kick-ass I/O stream package into
Phobos. It could replace std.stream as well as std.stdio.
Then our goals are aligned. Be sure to take a peek at (if you haven't
already):
https://github.com/schveiguy/phobos/blob/new-io/std/io.d
I have my share criticisms for it but it's a nice piece of work that
addresses many questions of I/O I've yet to consider.
Stuff like
serializers and lexers would be more robust and easier to write.
Indeed and even beyond that.
--
Dmitry Olshansky
