Re: [boost] Re: (Another) socket streams library

From: Jeff Garland (jeff_at_[hidden])
Date: 2005-04-22 08:08:35

On Fri, 22 Apr 2005 08:50:03 +0200, Michel André wrote

> So basically you propose something like using 
> basic_streambuf<unsigned char> or basic_streambuf<char> in the 
> interfaces instead of void*, size? 

Yes.

> The reason I haven't got any 
> buffer Is that I don't want to impose a buffering strategy or 
> interface onto the user.

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.

> Isn't streambuf interface more related to io with locale and 
> char_traits. 

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.  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.

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...

Jeff

ps: sorry I don't have more time to follow these discussions.  I haven't
really read all the posts and proposals that have been discussed recently :-(