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