[boost] Re: I/O library status

From: Daryle Walker (dwalker07_at_[hidden])
Date: 2003-06-04 18:23:18

On Monday, June 2, 2003, at 12:21 PM, Ed Brey wrote:

> 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?  Also, 
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.

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

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

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.

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.

> There are lower-level issues remaining, too, but these are more 
> appropriate to address after the high-level issues are resolved.

Daryle