"Rob Stewart" <stewart@sig.com> wrote in message:
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?
I'm torn. I'm trying to keep the number of library-defined types to an absolute minimum, since I've already had a complaint that there are too many names to remember.
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.
Yes, I think skip_line/skip_lines is a good combination.
- 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.
Yes. I found the padding example more convincing than the Haskel example, because of the extra functionality needed in the latter case.
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?"
I like plain old 'skip', which should be able to double duty as multi_skipper and skip_string: cin >> skip('c', 10) cin >> skip("hello world") In another post I also suggest skip_if and skip_to.
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.")
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
I like newline and newlines. 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?
Yes. I was too hasty in rejecting it. Even if it's called "newline", though, people may still wonder why it's being used instead of endl or "\n" and end up consulting the documentation.
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 do this stuff, too. The situation is different with library components, though. Imagine someone proposing a new container based on its performance characteristics but not presenting any performance data. At any rate, you and Reece have convinced me that my rejection of some of the manipulators was rash. I'm still not sure about ios_form; I'd like to hear Daryle's rationale. BTW -- Daryle, where are you??? I'd like to hear your answers to some of my objections. Best Regards, Jonathan