Re: sockets library

From: bill_kempf (williamkempf_at_[hidden])
Date: 2001-12-20 11:28:02

--- In boost_at_y..., "Andrei Alexandrescu" <andrewalex_at_h...> wrote:
> From: "mfdylan" <dylan_at_m...>
> > > Besides, many people have never been very fond of iostreams'
> > design...
> > >
> > From what perspective?  Certainly I've found that deriving a
> > streambuf class is unnecessarily messy.  But in general it works
> > better than I/O in most other languages.
> 
> An author of a very thick book on iostreams confessed about not 
liking
> iostreams and preferring Java's streams.

The author must have been smoking something ;).

Seriously, though, even if you consider iostreams to be a bad design, 
the Java streams are MUCH worse (at least from a C++ design 
perspective).  They are a huge pain to use and result in even more 
overhead than iostreams.

I don't consider C++ streams to be poorly designed, but there are 
definate areas that need improvement or simply need to be covered.  
For instance, locales are much more difficult to use then they should 
be, and there's little portability in their use (for instance there's 
no standardized IDs for given locales, so even if two platforms can 
represent all the locales you need you can't write portable code for 
constructing the specific locales).  Some facets are remarkably 
missing (for instance you can stream a date out, but you can't read 
it back in... and this would be a GREAT facet for some aspiring 
Booster to work on).  I also find it vexing that there's no support 
for binary output.  I think a binary_stream heirarchy would be a 
wonderful thing for Boost to address as well (however, it should be 
designed on it's own, not "hacked" in because Boost.Sockets or some 
other library needed it... this is too important to design with such 
a narrow view).  Speed is a bit of a concern with streams, but the 
extensibility is too great to make this very relevant to me (though 
it would be very nice to see faster implementations).

In other words, they are far from perfect, but they are much better 
than any known alternatives.

Bill Kempf