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

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-08-27 17:43:43

"Rob Stewart" <stewart_at_[hidden]> wrote in message:
> 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?

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.")

I like newline and newlines.

> > 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?

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