Re: [boost] [Ann] socketstream library 0.7

From: Aaron W. LaFramboise (aaronrabiddog51_at_[hidden])
Date: 2005-06-10 17:10:49

Simon Richter wrote:

> Hrm, I have never missed being able to access files from a lower level
> than iostreams so far. :-) I never do binary I/O directly in my
> applications but always implement an inserter/extractor pair that uses
> streambuf iterators, though.
> 
> 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.

What write()?

And as far as read(), can someone explain to me how its possible to use
this interface for anything other than files?  As near as I can tell, it
has no way of expressing how much data it actually read, which is
unacceptable, and useless, and really next door to defect-land in my
opinion.  readsome() returns streamsize, but this function isn't that
useful either, as it will never trigger a call to underflow().

Now, what exactly do iostreams offer to general socket work?  Most
socket protocol are defined in terms that have no correlation with C++
locales and whitespace-skipping rules.  In other words, the iostreams
concept of >> and << really isn't appropriate for sockets, even for
'text protocols,' because generally additional control will be needed.

Besides this, iostreams has many annoying characteristics that are
unacceptable for use in many robust sockets situations, such as reading
an indeterminant amount of characters, and then just throwing them away
if something goes wrong.

In other words, I'd suggest we forget about iostreams.  Design a good
socket based on past experience that handles diverse networking
situations elegantly, and let some other library like Boost.Iostreams
map that to a streambuf, should <iostream> support be needed.

Aaron W. LaFramboise