[RFC] I/O and Buffer Range

[Dmitry Olshansky]

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