Boost logo

Boost :

Subject: Re: [boost] [Range] New I/O functions for ranges
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2014-10-01 05:00:13

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Indiana
> Sent: 30 September 2014 21:53
> To: boost_at_[hidden]
> Subject: Re: [boost] [Range] New I/O functions for ranges
> On 14-09-29 01:24 PM, Paul A. Bristow wrote:
> > I wonder if you have studied the examples of Steven Watanbe's type
> > erasure library?
> >
> >
> >
> > I found this useful, but it didn't cover all the options that I
> > wanted, so I added a prefix string and a suffix string to the existing
delimiter string.
> >
> > I would urge you to consider this as it increases the possible
> > use-cases covered considerably.
> Well, the range I/O functions i'm proposing are not intended to cover every
> imaginable I/O situation. The goal is just to make the simplest cases - which
> the *VAST* majority of usage - simple to do. Trying to cover things that are
> complex, very rare, or that would require a ton of customization options (like
> automatic line wrapping) would add too much complexity for too little payoff.
> that's not really a cop out, because the truth is that the *VAST* majority of
> you might want to do are already covered.
> To demonstrate that, i took the code you pasted, and reimplemented it using
> write_all(). I tried to match the output exactly, and to keep the code in
> changed as little as possible except for the parts pertaining to output.
> Of the 19 output operations in the original code:
> * 13 could be done with just a call to write_all() and no additional code;
> * 5 could be done with (the same, reused) ~30 lines of additional code to
create a
> smart delimiter (these were the ones that print the range in columns in
> order);
> * 1 required ~100 lines of additional code to create a smart delimiter and
> adaptor (this was the one that prints the range in column-major order; because
> prints the range out of order, it requires a custom range adaptor to do the
> reordering).*
> You can see the code i wrote here: . In total the
> whole program came to ~300 lines (compared to the original at
> ~480 lines, around at least 40% less code). Not only that, every output
> handles formatting correctly. (Compare doing "std::cout <<
> std::setw(4) << std::setfill('0'); separator_printer p1(",");
p1.print(std::cout, test);
> std::cout << '\n';" to doing "std::cout <<
> std::setw(4) << std::setfill('0') << write_all(test, ",") << '\n';". The
former will print
> "0001,2,3,4,...", the latter will do
> "0001,0002,0003,0004,...".) And they also correctly handle I/O errors.

Neat :-)

The measure example

45210.(+/-1234.0) m, 789.00(+/-2.5000) m, 0.00056700(+/-2.3400e-05) m -

with uncertainty and units is particularly nice (and testing).

(I think I remember that there was a mistake in the example that fails to save
the IO settings for uncertainty).
> What I'm trying to demonstrate is: all the complexity you *think* you need in
> I/O functions... you probably don't. You will probably never find a case where
> you need in range output cannot be handled by a simple function that just
prints the
> range elements in order, possibly with a delimiter between. Anything else -
> reordering the elements, skipping elements conditionally, etc. - is outside
that scope;
> that is the domain of (for example) range adaptors (because you're adapting
> range). Combining range adaptors, smart delimiters, and
> write_all() will cover just about every range output situation you can
conceive of.
> So if we can get printing the elements of a range in order - possibly with a
delimiter -
> done *RIGHT* (ie, doing formatting, error handling, etc. right) and *EASY*,
then we
> will have covered a hell of a lot of ground. That is the philosophy i had in
mind, not
> trying to design an interface that can do *everything*.

You may well be right, but I'm only reporting what I found were my 'needs'.

You can show how to wrap write_all output (with 'smart' delimiter - no ugly
trailing commas!) with prefix and suffix strings, that will probably be fine.

> > In particular, it is seems desirable to be able to output values in
> > the C++ syntax for the compiler to read back in?

I only meant a string in C++ syntax like

  int[10] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};

that you have shown is possible.

> (*Incidentally, maybe there *should* be a column-major reordering range
> added to Boost. Or rather, a "transpose" adaptor that takes a forward range
that is
> presumed to be a MxN matrix in row major format, and returns a view of it
> transposed. I can see that as being generally
> useful.)

Now you need some enthusiastic users to support you on a review ;-)


Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
+44 (0) 1539 561830

Boost list run by bdawes at, gregod at, cpdaniel at, john at