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