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

From: Daryle Walker (dwalker07_at_[hidden])
Date: 2003-03-19 09:04:26

On Tuesday, March 18, 2003, at 8:32 AM, Ed Brey wrote:

> I'd like to thank those who took time to review the update to the 
> Boost I/O Library during the review period, which ended several days 
> ago.  The reviewers raised important questions about the usefulness of 
> the new portions of the library.
>
> As review manager, I am pending my determination regarding acceptance 
> until Daryle has had opportunity to respond to the reviewers' 
> questions.  In particular, there are a few very important high level 
> questions, mostly having to do with general rationale for libraries.  
> These questions are summarized below.
>
>
> 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.

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.

> Array-based streams:
>
> - Is there a real-life application?  (If none, then the class should 
> be made into an example or regression test.)

Originally, I didn't have any real-life applications.  I had this 
problem: a stream buffer class needed to be created to test the 
stream-buffer-wrapping classes.  However, the buffer class used had to 
be simple enough that we could check it by inspection.  (Otherwise, I 
wouldn't know if a test failed from a bug in the wrapper classes or the 
buffer they wrapped.)

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.

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

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

Daryle