[boost] Re: [Ann] socketstream library 0.7

From: pedro.lamarao_at_[hidden]
Date: 2005-06-11 07:32:13

Aaron W. LaFramboise wrote:
> 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()?

basic_ostream::write (char const*, streamsize) ?

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

basic_istream::gcount() ?

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

Most Internet protocols I've worked with or seen, such as HTTP or the
Jabber protocol, or mail messages extended with MIME, contain text
encoded in some charater set indicated in a header field. Try reading my
UTF-8 mail with your locale set to ISO8859-1 (or some Windows variation).

Most of these, and others such as FTP, are "text oriented", so to speak.
Most of these have a very well specified message format, such that can
be interpreted as the "serialized to this text" form of a message object.

Define such a class with proper operator<< and operator>> and check out
what kinds of semantics you can offer to user code. *This* is the great
benefit in my opinion, and the greatest usefulness of the iostreams library.

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

I don't understand what you mean here.

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

I sincerely have no idea what is the trouble everyone has with
iostreams. It's just a formatting layer over a buffer layer.

Every "socket library" or socket application without such library
support has reinvented a buffer layer; and none of them have considered
the usefulness of a formatting layer, leaving "sends" and "receives" as
high up as main().

None of these, be it iostreams, be it personalized buffering, attack the
complicated problems of IO efficiency, that end up being not blocking,
and not making a system call, when you don't absolutely need to.

--
 Pedro Lamarão