[boost] Re: Boost I/O Library review status

From: Ed Brey (brey_at_[hidden])
Date: 2003-03-19 12:12:28

Daryle Walker wrote:
>> Stream-buffer-wrapping:
>> 
>> - Why are these facilities provided?  What are their uses?  What do
>> they do better than the Standard Library's current classes?
> 
> I don't think the Standard Library has classes like these.  The
> standard streams (string, file, etc.) probably work by manually using
> the techniques these wrappers provide.  I wanted to provide a guide,
> rather than everyone rolling their own stream solution whenever they
> create a stream buffer class.  We already do this with utilities like
> boost::noncopyable.

This general description does cover the purpose.  However, it took me much longer than I would have liked to fully understand it.  To be fair, someone about to implement a new stream class would probably be more up to speed, since I haven't made such a class in over a year.  Still, a brief example like this may help:

For example, consider stringstream.  It contains as a member a buffer object of type stringbuf.  To make use of the buffer, stringstream must (1) hold a stringbuf as a member, (2) forward construction parameters to it, (3) expose its types, and (4) provide access to it.  These four requirements are common for many streams that wrap (that is contain) their own buffer.  This utility provides these four services.

> I considered a case that was overlooked in the Standard.  All streams
> allow you to change which stream buffer they use, even though that may
> not be a good idea when the stream has an internal stream buffer or
> when a stream uses another stream's internal buffer.  The new classes
> add accessors that detect the first case.

Your interface diverges from that of the existing streams.  For example, with a stringstream object s you use:

s.rdbuf()    to get the internal stream buffer.

and

s.std::basic_ios<char>::rdbuf()    to get the stream buffer in use.

Not that I'm crazy about this interface, or much of the function naming in the I/O interface in general, but I would expect custom streams will want to use the conventional approach for getting access to the various buffers.  It might be better to just define rdbuf, and not bother with get_internal_streambuf or is_using_internal_streambuf for the sake of keeping the interface minimal, since it is already complete.  What are your comments.

>> Array-based streams:
>> 
>> - Is there a real-life application?  (If none, then the class should
>> be made into an example or regression test.)
> 
> [...]
> 
> Dietmar Kuehl actually came up with suggestions to give the
> array-based stream buffer real uses.  That may be a better way to go
> than demoting the classes to tests/examples.

Can you articulate one or more of these use cases into text at the beginning of the documentation file?

>> Manipulators:
>> 
>> - Why newl?  When and why does the user use newl? endl? '\n'?  Why is
>> a third option justified?  (Presumably, much of the wisdom behind the
>> choice can be drawn from literature that inspired the creation of
>> newl.)
> 
> I read that some people were using std::endl as an object-based way to
> specify an end-of-line, without realizing the consequences of its
> extra effect (a flush).  I wanted to provide an alternative to endl
> without  its extra effects.  Using '\n' directly may have its own subtle
> effects (formatted printing vs. unformatted) that an object-based
> method can shield users from, since I (should) have taken care of all the issues.

It's interesting that the people you read about don't think of '\n' conceptually as an object.  Mis-use of endl doesn't seem to be adequet justification for a new end-of-line specifier.  However, a difference in behavior between '\n' and endl does.  Could you elaborate on the subtle effects you mention, and why they would compel a need for another way of indicating line termination?

>> - Why not other control functions, e.g. tab?
> 
> Never thought of it.  Anyway, the C and C++ standard libraries already
> have accommodations for line-based text processing, but not for other
> control characters.

True.  Presumably, then, the same subtle effects that would compel an alternative to '\n' wouldn't do likewise for '\t'.  Is that correct?