From: "Jonathan Turkanis" <technews@kangaroologic.com>
"Rob Stewart" <stewart@sig.com> wrote in message news:200408262114.i7QLEOP14442@lawrencewelk.systems.susq.com...
From: "Jonathan Turkanis" <technews@kangaroologic.com>
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;
Sure, but then every developer that wants one must write the same typedef. Why not standardize the name by providing it with the library?
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?
"skipl" is shorter than "skip_line" and I figured it would be used more frequently as a result. However, I really like "skip_lines" (as opposed to "multi_skipl") and extraction operations that need to skip lines are not terribly common, so the added length of "skip_line" and its symmetry with "skip_lines" makes it a win.
- 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.
Reece provided some useful examples. I hope they're sufficient. If not, I guess I could come up with some given a few minutes time. However, in keeping with the "skip_line" idea, perhaps this would be better named "skip_char?"
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.
It could be named "skip_string."
- 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.
Daryle can build his own defense on why he included multi_newer. It is cleaner than inserting the same character multiple times. You're right that it's not an improvement over inserting std::string('c', n). The name, of course, is a problem, too.
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).
As I said, I think "newl" is fine, as compared to "endl," but "multi_newl" is less satisfying than "newlines." (I prefer "newline" to "new_line.") I use an "nl" manipulator, so mine is even more cryptic than "newl," but I think it is fine. ("nls" doesn't work too well, though, as a name for the multiple nl version.) I suppose the question is whether multi_newer('\n'), with whatever name it might use, would be the better way to spell "multi_newl."
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.
I don't think many would have a hard time recognizing the parallel between "newl" and "endl." If you rename it to "newline," there's no chance of misunderstanding the manipulator, right?
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.
I use preincrement/predecrement unless I need the post* version so that my code is certain to be optimal. I create an end iterator outside of any loops that I may write so that the end() mf isn't evaluated each time through the loop. There are many things that I do out of habit that ensure that I'm writing the most efficient code I can before I profile to find algorithmic hotspots to address. I see the use of a newline manipulator as another such tool that ensures that inserting a newline isn't something someone would have to revisit when looking to improve performance. IOW, the penalty for inserting '\n' or "\n" may not matter, but with a newline manipulator, I can expect it won't ever be the problem. (If it is, then its only one of many operations that are a problem and I'd need to use a different I/O scheme altogether.) -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;