|
Boost : |
From: Simon Richter (Simon.Richter_at_[hidden])
Date: 2005-06-09 19:26:17
Hi,
Stefan Seefeld wrote:
> See ? As soon as you don't care for formatting you do want access to
> the underlaying streambuf object, which, in this case, would be a much
> more suitable place to put the extra API to manipulate socket-specific
> options.
Hrm, that would basically mean making the "impl" API in my model a
public API for application programmers as well as the socket_streambuf.
The stream classes need to pass the socket-specific API calls down to
the actual implementation anyway, so there is no big harm being done here.
>> iostreams' read()/write() should be enough for stream-based I/O, and for
>> datagrams I'd propose going through another step anyway (i.e. have a
>> separate stream class that does not derive from the standard iostreams
>> but rather allows inserting and extracting packets only.
> Why use iostream's read if you can do that on the streambuf object
> directly.
Easier interface.
> And, why use the concept of a 'stream' at all when dealing with datagrams ?
> That doesn't sound like a good fit to me.
It it a stream of packets, not an iostream. There is no real need to
call it a "stream" as well, but I think it should provide operator<< and
operator>> for packets.
Simon
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk