Re: [boost] IOStreams formal review start

From: Daryle Walker (darylew_at_[hidden])
Date: 2004-08-30 04:11:53

On 8/28/04 8:09 PM, "Jeff Garland" <jeff_at_[hidden]> wrote:

> Today (August 28th, 2004) is the start of the formal review of the Iostreams
> library by Jonathan Turkanis. I will be serving as review manager.  Note that
> this is a somewhat unusual situation in that we have several libraries that
> overlap in the same area, so comments related to the MoreIo overlap are
> needed.
> 
> As usual, please state in review comments how you reviewed the library and
> whether the you think the library should be accepted into Boost. Further
> guidelines for writing reviews can be found on the website at:
> 
> http://www.boost.org/more/formal_review_process.htm#Comments
> 
> **********************************************
> Library Synopsis
> **********************************************
> The Iostreams Library serves two main purposes:
> 
> * To allow the easy creation of standard C++ stream and stream buffer classes
> for new data sources and sinks.
> * To provide a convenient interface for defining i/o filters and attaching
> them to standard streams and stream buffers.
> 
> The library focuses on freeing users from writing boiler plate code and
> allowing them instead to create highly reusable components.
> 
> In addition to providing an abstract framework the library provides a number
> of concrete filters, sources and sinks which serve as example applications of
> the library but are also useful in their own right. These include components
> for accessing memory-mapped files, for file access via operating system file
> descriptors, for code conversion, for text filtering with regular expressions,
> for line-ending conversion and for compression and decompression in the zlib,
> gzip and bzip2 formats.
> 
> The latest package can be found at the following locations:
> 
> http://home.comcast.net/~jturkanis/iostreams/

Some concerns over what qualifies:

1.  Aren't memory-mapped files and file descriptors highly platform
specific?  Code that works with them would have to be non-portable, so I
don't think they're appropriate for Boost.

2.  This library does what a lot of other text-I/O libraries do, try to fit
in "kewl" compression schemes.  The problem is that the types of compression
here are binary oriented; they convert between sets of byte streams.
However, characters are not bytes (although characters, like other types,
are stored as bytes).  There are issues of character-to-byte-sequence
conversion.  These issues, and binary I/O itself, should _not_ be snuck in
through a text-I/O component.  Worse, we have an upcoming library
(Serialization) that also has to deal with binary I/O stuff, so we should
have a binary I/O strategy.  That means that the compression stuff should be
skipped for now.

    (If someone says that this library is supposed to be text and/or binary
I/O, that's even worse!  The two types should be distinct and not just
glommed together.)

Now to the review itself:

1.  Actual code using this library is very slick and easy to set up.  This
ease of use/set-up also applies to the plug-in filters and/or resources.

    The end-user experience is so awesome that we could just say "ship it"
and go home.  However, the experience is the only good point.  That ease
comes with a nasty little price tag, or more accurately, a nasty BIG price
tag.

The core question on keeping this library is:

    Besides filtering/chaining, is there any part of the interface that
    isn't already covered by the standard stream (buffer) system?

The whole framework seems like "I/O done 'right'", a "better" implementation
of the ideas/concepts shown in the standard I/O framework.  The price is a
code size many times larger than the conventional system, and a large chunk
of it is a "poor man's" reflection system.

Yes, filtering is very important.  Maybe Jonathan should have just added a
filtering stream-buffer base class (that chains together).  That, combined
with the existing I/O framework, using custom stream-buffer classes for new
initial sources/sinks, should give an equivalent to Iostreams' framework.

1a. An issue that appeared during the previous review (my More-I/O library)
was the necessity of the stream base classes that could wrap custom
stream-buffer classes.  The complaint was that the wrappers couldn't be a
100% solution because they can't forward constructors, so a final derived
class has to be made the manually carries over the constructors.  Well, that
is true, mainly because C++ generally doesn't provide any member forwarding
(besides in a limited way with inheritance).  The sample stream-buffer in
More-I/O generally had added-value member functions attached, that perform
inspection or (limited) reconfiguration.  Those member functions also have
to be manually carried over to the final derived stream class.  The point
(after all this exposition) is that the More-I/O framework at least
acknowledges support for value-added member functions.  The Iostreams
framework seems to totally ignore the issue!  (So we could have a 90%
solution for a quarter of the work, but triple the #included code length!)

2.  Another issue that appeared during the More-I/O review was that plug-ins
for Iostreams could be used for other ultimate sources/sinks unrelated to
standard streams.  What would those be?  If a system in question supports
Standard C++, it probably uses the Standard I/O framework for (text) I/O.
If the system doesn't/can't use Standard I/O, it has to use a custom I/O
framework.  To use it with Iostreams framework plug-ins, an adapter would
have to be made for the custom I/O routines.  In that case, an adapter could
be made for the Standard I/O framework instead.  (As I said in the prelude,
I'm skipping over binary-I/O concerns.)

To sum it up:

    I would REJECT the library (at least for now).  Maybe chain-filtering
    stream-buffer and stream base classes could be made instead?

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT hotmail DOT com