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