Re: sockets library

From: bill_kempf (williamkempf_at_[hidden])
Date: 2001-12-21 10:53:47

--- In boost_at_y..., Ross Smith <r-smith_at_i...> wrote:
> bill_kempf wrote:
> > 
> > --- In boost_at_y..., Ross Smith <r-smith_at_i...> wrote:
> > 
> > > 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.
> 
> Fair enough; if you can come up with a binary I/O library that 
doesn't
> derive from standard iostreams (while still using standard 
streambufs)
> and doesn't bring locales in, I'll withdraw my objections. But I 
don't
> entirely think it's reasonable to call it a "binary iostream"; to 
me the
> term "I/O streams" necessarily implies something derived from 
standard
> iostreams, and that's what I've been assuming so far.

I didn't call it a binary_iostream, I called it a binary_stream ;).

There are a number of technical reasons why I don't think you can (or 
at least would want to) make a binary stream derived from any of the 
iostream classes in the standard.  There's a LOT of baggage in 
iostreams that is text formatting specific.  The only thing you can 
borrow from the standard is the streambufs, but this is enough to add 
significant functionality right away.

The only draw back to this is that you need to create inserters and 
extractors for both text and binary stream types (if you need the 
functionality).  But this has to be the case since the text inserters 
and extractors have to deal with formatting issues that binary 
inserters and extractors don't.

> If someone writes such a class that would be great (I don't know 
enough
> about the arcane details of streambufs to attempt it myself), but I
> don't think its name should include the word "stream", to avoid
> misleading people into thinking it's an iostream in the C++ standard
> sense.

Such a class *WOULD* be a stream, though, even though it's not a text 
stream.  I don't think the name should be changed.  For instance if 
we called it a store instead of a stream wouldn't you find it awfully 
strange that it operates on a *stream*buf instead of a storebuf?

I don't think a binary stream library would be too difficult to 
create, even in a portable manner.  Another post worried about the 
standard excepting such a concept because of the problems with 
dealing with the vagaries of floating point representations... but 
this only effects concepts such as XDR which should be optional 
pluggable extensions any way.  Native formatting should be the 
default.  Other formatters, such as a socket formatter that used 
ntohs/ntohl/etc. could throw an exception if a floating point type 
were used since such a type isn't compatible any way.  An XDR 
formatter would simply be an optional extension for the platforms it 
can be done on (and I believe XDR works on most platforms any way).

The key, though, is to ignore sockets for now.  Design the binary 
streams to work with native formats but provide an extension to allow 
for pluggable formatting concepts, similar to codecvt.  Use the 
standard streambufs for wiring the data.  This gives the most 
flexibility.  Once you get back to socket design you can then quickly 
create a socketbuf derived streambuf which can be reused for both a 
simple text socket_stream and binary_socket_stream.  Neither of these 
solve the need for datagram support so a full featured socket library 
wouldn't be complete yet, but it would be a heck of a good start.

I also agree with Jeremy, though, there should be some higher level 
abstractions as well, which can eliminate a lot of usage bugs.

Bill Kempf