[SG16-Unicode] std::byte based I/O library

Lyberta lyberta at lyberta.net
Sat Feb 16 04:00:00 CET 2019


JeanHeyd Meneide:
> Dear Lyberta,
> 
>      Apologies for the delay. I think the point I'm trying to make is that
> your stream type should not include the state at all.

Well, first, I think we should define what kind of state there is. The
essential state is the current position in the stream and possible error
state maybe. iostreams have these 4 bits of std::ios_base::iostate that
I still use in my library for now.

Another kind of state is format state that defined how IO should be
performed.

>      The only operations the stream type has is "std::io::read( stream,
> buffer, length )" and "std::io::write( stream, bytes, length )".
Everything
> else on the stream object should be for the sole purpose of supporting
> those 2 operations, and literally nothing else. (Maybe async versions as
> well, etc.)

My design has raw read and write as member functions:

void read(std::span<std::byte> buffer);
void write(std::span<const std::byte> buffer);

std::io::read and std::io::write are customization points.

>      Note the proper separation of concerns. Now, stream has one job and
> one job only: writing and reading bytes. The serializer can be made to
have
> all the customization points in the world, all the state it wants, and all
> the functionality, but now none of it gets in the way of whatever the
> stream object is supposed to be doing. The serializer's only job is to ask
> things that get serialized:

I agree that if we want to make a separate type for reading text more
akin to iostreams, it seems like a good idea. Not sure about other types.

I guess I'm gonna write a synopsis of my design so we can have a more
tangible discussion.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
Url : http://www.open-std.org/pipermail/unicode/attachments/20190216/7509ce41/attachment.bin 


More information about the Unicode mailing list