From: Rob Stewart (stewart_at_[hidden])
Date: 2004-08-27 11:42:54
From: "Jonathan Turkanis" <technews_at_[hidden]>
> "Rob Stewart" <stewart_at_[hidden]> wrote in message
> > From: "Jonathan Turkanis" <technews_at_[hidden]>
> > >
> > 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
> > 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
> > 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,
> > 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_at_[hidden] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk