Re: [boost] Re: Re: Review of Daryle Walker's "More IO" library beginstoday, August 21, 2004.

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
> news:200408262114.i7QLEOP14442_at_lawrencewelk.systems.susq.com...
> > 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
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_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;