[boost] Re: I/O library status

From: Daryle Walker (dwalker07_at_[hidden])
Date: 2003-06-07 01:58:44

On Thursday, June 5, 2003, at 8:26 AM, Ed Brey wrote:

[SNIP]
>>> * 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?

An user can create a stream buffer class to do any sort of character 
filtering and/or redirection.  If you're making a custom stream buffer 
for one use in proprietary code, the manual method may suffice.  
However, creating stream buffers for library code (e.g. Boost) would be 
user-unfriendly if the users were forced to do all the stream lifetime 
and connection management.  (Note that the standard library follows 
this guideline by providing stream classes for its custom stream 
buffers.)

[SNIP]
>>> * 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?
[TRUNCATE]

You misunderstood my last paragraph; the width attribute and locale 
mechanism effects are independent of each other.

Sometimes people want to print something at a certain width.  Any 
formatting printing call resets the width[1], so the user has to make 
sure to set the desired right before the formatted print.  It's OK to 
intersperse unformatted calls since they don't affect the width 
setting.  The user would have to be careful about line-break placement 
with "<< '\n'" versus "<< newl" so they don't reset the width too soon.

The locale mechanism is big & complicated, and is generally involved in 
the formatting printing calls, but not the unformatted ones.  There can 
be a execution time savings if unnecessary locale checks are avoided.

Daryle