Re: sockets library

From: bill_kempf (williamkempf_at_[hidden])
Date: 2001-12-20 11:39:53

--- In boost_at_y..., Ross Smith <r-smith_at_i...> wrote:
> Rainer Deyke wrote:
> > 
> > From: "Ross Smith" <r-smith_at_i...>
> > 
> > > I'm convinced that iostreams should be reserved strictly for 
human
> > > readable text I/O, and not used for computer-to-computer 
communication,
> > > such as sockets.
> > 
> > Right now I'm using my own binary serialization layer on top of 
iostreams.
> > This allows me to read and write binary files.  Why should I need 
to change
> > my code if I want to read from / write to sockets instead?
> 
> Because that's a ridiculously inefficient way of doing binary I/O, 
and
> some of us don't want to be forced to pay the penalty merely because
> other people consider it acceptable.

There's no evidence that a binary_stream need to be inefficient.  In 
fact the majority of overhead in iostreams comes from locales and 
formatting facilities, both of which would not exist in a 
binary_stream.  I'd be willing to bet that we could develop a 
binary_stream that was as efficient as a lower level abstraction, and 
there's a lot of power that comes from such a design.  For instance 
it becomes quite easy to define inserters and extractors for 
arbitrary types, allows for pluggable converters for native 
representations, XDR representations, etc.

Further, if the binary_stream uses an streambuf to wire the data then 
you can easily create buffer types for anything that work with both 
binary and formatted I/O.  A single socketbuf class would allow you 
to use binary I/O (possibly with an XDR representation) in one 
instance and formatted text I/O (which can be much easier to use for 
some protocols) in another instance.

> Iostreams are a disaster area; they violate the "you don't pay for 
what
> you don't use" rule right left and centre. Let's not throw good code
> after bad, please.

This is only true if a basic_binary_istream were derived from 
std::basic_istream, which is going to be nearly impossible to do any 
way.  However, borrowing the design and making use of streambufs can 
make the design much more powerful, extendible and interoperable with 
existing code, and really shouldn't cause much (any?) overhead.

Bill Kempf