[boost] Re: I/O library status
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 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: I/O library status
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. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: I/O library status
Daryle, On Thursday 05 June 2003 01:28, Daryle Walker wrote: > > Actually, that reason isn't accurate. The '\n' is an expression of > type char, and all output streams can print a char object with operator > <<, even if the stream's character type isn't char. (The stream will > secretly call the widen member function.) Yep, you are right. This will tell me to stop talking about io issues from memory ;-). Thomas -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: I/O library status
On Tuesday, June 3, 2003, at 9:19 AM, Thomas Witt wrote:
[SNIP]
To me there are basically two reasons that make newl desirable beside
the formatting issue.
[SNIP]
2. IIUC the difference between a character and a manipulator is that
the manipulator is not tied to the streams character type. So for some
applications '\n' does not suffice. To me stream.widen('\n') is
sufficiently ugly to justify a newl modifier.
Actually, that reason isn't accurate. The '\n' is an expression of
type char, and all output streams can print a char object with operator
<<, even if the stream's character type isn't char. (The stream will
secretly call the widen member function.) Unlike using a manipulator,
printing a character this way also activates all the formatting
considerations.
Daryle
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: I/O library status
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 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: I/O library status
I agree with these conclusions and strongly support the addition of newl.
Paul
Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK
+44 1539 561830 Mobile +44 7714 33 02 04
Mobile mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
| -Original Message-
| From: [EMAIL PROTECTED]
| [mailto:[EMAIL PROTECTED] Behalf Of Thomas Witt
| Sent: Tuesday, June 03, 2003 8:19 AM
| To: Boost mailing list
| Subject: Re: [boost] Re: I/O library status
|
|
|
| Hi,
|
| On Monday 02 June 2003 19:21, Ed Brey wrote:
| > * 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?
|
| To me there are basically two reasons that make newl desirable beside the
| formatting issue.
|
| 1. std::endl was and is still abused heavily. I think there is a reason for
| this. Most c++ programmers are taught to stay clear of ugly low-level c
| things and to use the new shiny c++ facilities instead. And that's what they
| do, replace '\n' with std::endl. Personally I believe this reason alone
| justifies a std library extension std::newl.
|
| 2. IIUC the difference between a character and a manipulator is that the
| manipulator is not tied to the streams character type. So for some
| applications '\n' does not suffice. To me stream.widen('\n') is sufficiently
| ugly to justify a newl modifier.
|
| Thomas
|
| --
| Dipl.-Ing. Thomas Witt
| Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover
| voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001
| http://www.ive.uni-hannover.de
|
| ___
| Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
|
|
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: I/O library status
Hi,
On Monday 02 June 2003 19:21, Ed Brey wrote:
> * 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?
To me there are basically two reasons that make newl desirable beside the
formatting issue.
1. std::endl was and is still abused heavily. I think there is a reason for
this. Most c++ programmers are taught to stay clear of ugly low-level c
things and to use the new shiny c++ facilities instead. And that's what they
do, replace '\n' with std::endl. Personally I believe this reason alone
justifies a std library extension std::newl.
2. IIUC the difference between a character and a manipulator is that the
manipulator is not tied to the streams character type. So for some
applications '\n' does not suffice. To me stream.widen('\n') is sufficiently
ugly to justify a newl modifier.
Thomas
--
Dipl.-Ing. Thomas Witt
Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover
voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001
http://www.ive.uni-hannover.de
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: I/O library status
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. * Stream-buffer-wrapping Streams motivation: Why would someone want an internal buffer (versus independent buffers as used by standard streams)? (Example, please.) * Array-Based Streams motivation: When is the class more suitable than std::stringstream? (Example, please.) * 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? There are lower-level issues remaining, too, but these are more appropriate to address after the high-level issues are resolved. Ed Brey Review Manager for I/O Library update ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: I/O library status
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. Besides an altered "boost/io_fwd.hpp" and "libs/io/doc/index.html", we got: boost/io/array_stream.hpp boost/io/iomanip.hpp boost/io/streambuf_wrapping.hpp libs/io/doc/array_stream.html libs/io/doc/iomanip.html libs/io/doc/streambuf_wrapping.html libs/io/test/array_stream_test.cpp libs/io/test/iomanip_test.cpp I got a question with the implementation of a class, I'll put it in a separate message. Daryle ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
