Re: [boost] [Range] New I/O functions for ranges

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?
> >
> > http://www.boost.org/doc/libs/1_55_0/doc/html/boost_typeerasure.html
> >
> > 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
cover
> the *VAST* majority of usage - simple to do. Trying to cover things that are
very
> 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.
But
> that's not really a cop out, because the truth is that the *VAST* majority of
things
> 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
main()
> 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
row-major
> order);
>   *  1 required ~100 lines of additional code to create a smart delimiter and
range
> adaptor (this was the one that prints the range in column-major order; because
it
> prints the range out of order, it requires a custom range adaptor to do the
> reordering).*
> 
> You can see the code i wrote here: http://pastebin.com/R1SwvBEr . 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
statement
> 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
range
> I/O functions... you probably don't. You will probably never find a case where
what
> 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 -
like
> reordering the elements, skipping elements conditionally, etc. - is outside
that scope;
> that is the domain of (for example) range adaptors (because you're adapting
the
> 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
adaptor
> 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
 
---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
[phone]