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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
