Re: [boost] sockets library

From: Jani Kajala (jani_at_[hidden])
Date: 2001-12-20 15:06:34

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

It's true that there is no single big fat stream class which would be
immediately there to use, but filter design of Java io is more flexible,
efficient and definitely better than iostreams. Using output of one stream as in
input to another is a very powerful concept. You should not underestimate the
powers of the dark side.

Regards,
Jani Kajala

----- Original Message -----
From: "bill_kempf" <williamkempf_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, December 20, 2001 6:28 PM
Subject: [boost] Re: sockets library

> --- 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
>
>
> Info: http://www.boost.org  Send unsubscribe requests to:
<mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>