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

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-08-26 17:18:22

"Rob Stewart" <stewart_at_[hidden]> wrote in message
news:200408262114.i7QLEOP14442_at_lawrencewelk.systems.susq.com...
> From: "Jonathan Turkanis" <technews_at_[hidden]>
> >
> > <boost/io/null_stream.hpp>:
> >
> > I don't understand the stated rationale for this stream. Are you
> > saying someone might want to use it to implement a command-line
> > interface?
>
> It may not be worded extremely well, but it certainly doesn't say
> that.

I know it doesn't say that ... I was trying to fill in the blanks.

> > An alternative rationale would be this: sometimes a C++ interface
> > requires that the user pass an ostream to receive output, but the user
> > doesn't care about the output. I have seen a request for a stream like
> > this on comp.lang.c++, and I think it would be a moderately useful
>

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

> > - basic_ios_form: I don't understand what this template is supposed to
> > do. You need a better description and some examples. Otherwise, I vote
> > to reject.
>
> It wasn't clear to me either, but I think I understand it to
> provide a means to capture a set of manipulations one wants
> applied to a stream so that the entire set can be applied at
> once.

I see. That does sound useful. My vote to reject is really a challenge to
Daryle -- I don't feel I should have to wade through the reference documentation
or the source to figure out what a component is supposed to do.

> That really lends itself to writing readably.  You can also
> assume that a using directive is in effect, yielding:
>
>    cout << setfill(' ') << setprecision(3) << setw(10) << ...
>
>    cout << basic_ios_form().fill(' ').precision(3).width(10) << ...
>
> That tips the scale in favor of the std manipulators.

Also, the former can easily be broken over several lines:

     cout << setfill(' ')
          << setprecision(3)
          << setw(10)
          << ...

But it's a matter of taste.

> > - skipl, multi_skipl: These sound useful too, though I agree with
> > Pavel that the names are too cryptic.
>
> 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?

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

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

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

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

> > - newl: This is a good idea. But I think this may be one of the rare
> > components which I would like to see added to the standard library but
> > not to boost. If it were part of the standard, every C++ programmer
> > would be expected to know what it means. But I can't see myself
> > including a boost header just to avoid writing "\n": most people
> > won't know what newl it means, so rather than being self-documenting
> > using it would be self-obfuscating. I vote to reject.
>
> That seems a particularly bad approach.

In general, yes.

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

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

Best Regards,
Jonathan