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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk