[boost] Re: (Another) socket streams library

From: Michel André (michel.andre_at_[hidden])
Date: 2005-04-22 09:11:41

Jeff Garland wrote:
> Socket data needs to be buffered somehow and there might be good reasons why
> the application programmer would want some control over that buffer.  But
> using unsized/unsafe void*, char* is a choice to be avoided.  As for imposing,
> the interface to control the buffer options should be 'optional'.  Suitable
> defaults provided by the library.

Even at layer0 a facade over socket api? I don't really see the absolute 
need for a buffer concept in a socket library at some level we need just 
to shuffle the bytes back and forth, and want to avoid copying the data 
to many times along the way.

> The interface is almost exclusively about seeking, getting, and putting into a
> buffer.  It does have a locale as well...
> 
> 
>>Wouldn't a simpler concept do just buffer with just 
>>checked read/write and size/resize.
> 
> 
> Sure you could probably create a simplier buffer concept, but basic_streambuf
> is already documented and comparatively well understood.  

Comparatively it was ;), it isn't the most beautiful and simple 
interface in the standard library by my view at least ;) not to talk 
about the naming.

 > It has the
> significant advantage that an iostream can be wrapped around it for formatted
> reading and writing. It's a way of separating the I/O issues so that the
> socket classes only use buffers and then users can decide to use streams on
> top -- or not.  A combination approach might be to write a minimal buffer
> concept that could be then implemented as a derivative of basic_streambuf, but
> could have non-streambuf versions for those that want something else.

Do you have any specific ideas how the interface to the socket library 
would look like and how the concept would be used?

> Anyway, it's just an idea.  My main point is that the unsafe, unknown size
> char buff decision is just not acceptable.  To me the issue is big enough to
> vote against a library that doesn't doesn't address it...

what about basic_ostream::write and basic_istream::read?

/Michel