"Rob Stewart" <stewart@sig.com> wrote in message news:200408262114.i7QLEOP14442@lawrencewelk.systems.susq.com...
From: "Jonathan Turkanis" <technews@kangaroologic.com>
<boost/io/null_stream.hpp>:
I don't understand the stated rationale for this stream. Are you saying someone might want to use it to implement a command-line interface?
It may not be worded extremely well, but it certainly doesn't say that.
I know it doesn't say that ... I was trying to fill in the blanks.
An alternative rationale would be this: sometimes a C++ interface requires that the user pass an ostream to receive output, but the user doesn't care about the output. I have seen a request for a stream like this on comp.lang.c++, and I think it would be a moderately useful
That's an important distinction, over and above any simplicity of definition. You should provide a null sink, source, istream, and ostream in your submission.
My feeling is that once you have the null sink (or source), you don't need to include the streams in the library, since its so easy to write typedef stream_facade<null_sink> null_ostream;
- basic_ios_form: I don't understand what this template is supposed to do. You need a better description and some examples. Otherwise, I vote to reject.
It wasn't clear to me either, but I think I understand it to provide a means to capture a set of manipulations one wants applied to a stream so that the entire set can be applied at once.
I see. That does sound useful. My vote to reject is really a challenge to Daryle -- I don't feel I should have to wade through the reference documentation or the source to figure out what a component is supposed to do.
That really lends itself to writing readably. You can also assume that a using directive is in effect, yielding:
cout << setfill(' ') << setprecision(3) << setw(10) << ...
cout << basic_ios_form().fill(' ').precision(3).width(10) << ...
That tips the scale in favor of the std manipulators.
Also, the former can easily be broken over several lines: cout << setfill(' ') << setprecision(3) << setw(10) << ... But it's a matter of taste.
- skipl, multi_skipl: These sound useful too, though I agree with Pavel that the names are too cryptic.
std::endl is the precendent. I don't think skipl is too cryptic. Making it less so means making it longer and that reduces its value as a manipulator. (Too cryptic outweights a short name, but I don't think this fits the "too cryptic" category.)
Why are skipl and multi_skipl better than skip_line and skip_lines?
- multi_skipper: I'm not sure I see why this is needed; how often do you need to skip a sequence of repeated characters? Id rather
When parsing, it is often useful to ensure that there were exactly 10 spaces between one token and the next, for example.
I'll take your word for it, but an example would help. I am used to just worrying about whitespace.
see a utility that skips a certain specified sequence of characters, and sets failbit otherwise, as described by Dietmar Kuehl here: http://tinyurl.com/3jzwg
I agree that the generalized version that permits skipping an arbitrary string is likewise useful, but to duplicate multi_skipper's functionality, you'd have to create a string with the desired number of a character and then skip that.
I agree that the component I suggested would be a poor substitute for the original component, if the latter is in fact useful.
- multi_newer: How often do you need to write multiple copies of a character to a stream? And isn't it easy to do so already? The name is bad, too. I vote to reject.
I'm sure one doesn't need to write multiple copies of a character to a stream too often, but why reject this manipulator on the grounds that it isn't needed very often?
Because it clutters up the library, making it harder for people to find the parts they really need. Also, the straightforward way of writing a sequence of repeated characters to a stream makes it immediately obvious what is being done, whereas programmers looking at code written by someone else can't be expected to know what multi_newer does. If a component fills an important need, it's reasonable to expect people to learn about it if they want to understand your code -- otherwise, I don't see the point.
There are occasions in which one wants to insert multiple newlines. As a complement to newl, I don't see a problem with keeping multi_newl.
If both are accepted, I'd like them to be called new_line and new_lines (or newline and newlines).
- newl: This is a good idea. But I think this may be one of the rare components which I would like to see added to the standard library but not to boost. If it were part of the standard, every C++ programmer would be expected to know what it means. But I can't see myself including a boost header just to avoid writing "\n": most people won't know what newl it means, so rather than being self-documenting using it would be self-obfuscating. I vote to reject.
That seems a particularly bad approach.
In general, yes.
It won't get into the Standard for quite some time and, in the meantime, users can use it and prove its soundness and value.
The main benefit of newl (I think) is that it calls attention to a character which receives special treatment in some contexts. It can't achieve this purpose unless people know what it means. I wouldn't want someone examining my code to spend time looking through boost documentation only to find that the manipulator just writes a newline.
As it happens, inserting "\n" is slower than using newl because of the formatted I/O logic of streams and because of the invocation of (in effect, at least) strlen().
My guess is that in typical cases this difference is miniscule. If this is an important part of the rationale, I'd like to see some performance data. Best Regards, Jonathan