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