[boost] Re: I/O library status

From: Ed Brey (brey_at_[hidden])
Date: 2003-06-05 08:26:03

Daryle Walker wrote:
>>> I fixed up the I/O library I had reviewed a few months ago.  It was
>>> some little things last week, but some big documentation and testing
>>> this week.  It's in the sandbox if you want to try it out.
>> 
>> Looking at today's version in the sandbox, I still see the following
>> high-level questions from the formal review looming without clear
>> answers.
> 
> Didn't we go over these questions during the main review period? 

The questions came up, and there were some beginnings of answers, but nothing concrete.  In particular, for the "when would anyone ever use this" questions, no reviewer ever came back with, "Oh yeah.  That's an example of an application that could really use this library."

> I hope the new stuff in the documentation provides explanations.
> 
>> * Stream-buffer-wrapping Streams motivation: Why would someone want
>> an internal buffer (versus independent buffers as used by standard
>> streams)?  (Example, please.)
> 
> The basic stream (template) classes support attaching a stream buffer
> after the stream is constructed.  However, that technique is not used
> for the two example stream categories in the standard (files and
> strings).  The standard example streams act if they contain their
> appropriate stream buffer and make the proper connections to it.  The
> templates I provide just aid in an user simulating that effect.
> 
> I've been considering contributing several stream categories to Boost.
> Unless I just offer the custom stream buffers by themselves and make
> the user do the stream allocations and connections, I would have to
> supply matching custom stream classes with manual stream buffer
> containment and connection.  Instead of writing lots of custom code, I
> realized that I could have the computer help with the repetition, and
> that's where the idea of the stream-buffer-wrapping streams came from.

This is a good write-up, better than what, IIRC, is the latest version of the docs.  Please consider incorporating it.  IMHO, I only see one questions that remains in order to clearly justify the class for inclusion: What is an example of another stream buffer (in addition to string and file) that someone would want to internalize within a stream class?

>> * Array-Based Streams motivation: When is the class more suitable
>> than std::stringstream?  (Example, please.)
> 
> You generally wouldn't use these streams over string-based streams.
> The only advantage is that the storage for the characters is
> non-dynamic.  That could help in memory-restrained environments.

Perhaps this is the answer to my question above.  To be such, this class needs to be justified as practical.  Can you think of an application that can afford the overhead of streams but can't afford the overhead (or some other characteristic) of stringstream?

>> * newl differs from '\n' only in that newl doesn't perform background
>> formatting.  Presumably one would choose to use newl to avoid the
>> formatting.  What is undesirable about '\n' being formatted?
> 
> Formatted printing calls usually reset the width attribute and go
> through the locale mechanism.  Unformatted calls don't do either.

Understood.  But what problem does resetting the width passing '\n' through the locale mechanism cause?

> There is also the argument that boost::newl looks better because it's
> object based, instead of using a raw '\n'.  People wanting an object
> based style now use std::endl, which carries the extra flush.  That
> flush usually isn't wanted and adds an extra step.

I agree that endl is no substitute for '\n' when a flush is not desired.  I don't follow the logic of avoiding '\n' because of a desire for something "object-based".  '\n' is an object.

> Finally, the standard has a manipulator for flushing (std::flush) and
> one for a line-break & flush (std::endl).  This manipulator fills the
> hole; something that just does a line break.

Manipulators are needed in both those cases because characters can't flush.  In the case of a non-flushing output, there is no hole to fill, since '\n' already does that.