iterator range output format, and for IO adaptor

[Akira Takahashi <faithandbrave@…>]

When output Range of {1,2,3} by iterator_range_io, it becomes format : "123". In this format, it is difficult(or impossible) to parse.

I propose, the new range format inspired by Oven : "{1,2,3}". This proposal is break change, but the present format wouldn't be used.

Additionally, it propose identities Range Adaptor that Range adapt to iterator_range. It can be used to output a standard container easily. This was inspired by Oven, too.

​http://p-stade.sourceforge.net/oven/doc/html/oven/utilities.html#oven.utilities.io_hpp

​http://p-stade.sourceforge.net/oven/doc/html/oven/range_adaptors.html#oven.range_adaptors.identities

[Akira Takahashi <faithandbrave@…>]

source file, and test.

[Akira Takahashi <faithandbrave@…>]

Sorry, since description was bad. it re-description.

--

When Range {1,2,3} is output by iterator_range_io, its format is "123" which is difficult (or impossible) to parse.

I propose, the new range format inspired by Oven : "{1,2,3}". This proposal is break change, but the present format wouldn't be used.

I also propose "identities Range Adaptor" which adapts Range to iterator_range. The adaptor enables you to use standard containers easily. This was inspired by Oven, too.

​http://p-stade.sourceforge.net/oven/doc/html/oven/utilities.html#oven.utilities.io_hpp

​http://p-stade.sourceforge.net/oven/doc/html/oven/range_adaptors.html#oven.range_adaptors.identities

[Neil Groves]

I will maintain compatibility. Not producing delimiters by default is exactly what I intended and continue to believe is the correct default. I have many users that use this facility to stream binary messages, for example.

I will investigate a solution that learns from the Oven solution and achieves the same result. I hope this compromise will reassure those using the library currently that breaking contract changes will not occur, while providing sufficient resolution to your needs.

Generally I think I need to be talking with p-stade to bring some of the great ideas into Boost.

Thank you for your report. I intend to have this resolved for Boost 1.45

[giecrilj@…]

BTW, outputed is not an English word (in comment).

[giecrilj@…]

Syntax

(cout << separated (range, " "))

Implementation

namespace boost 
{ 
namespace detail 
{ 
template < class P_R, class P_C > 
struct output_range 
{ 
typedef P_R range_type; typedef P_C char_type; 
  range_type const &m_range; char_type const *m_sep; 
  inline output_range 
  (range_type const &p_r, char_type const p_s []) 
    :m_range (p_r), m_sep (p_s) {}}; 
  template < class P_R, class P_C, class P_T > 
  inline ::std ::basic_ostream < P_C, P_T > 
  &operator << 
  (::std ::basic_ostream < P_C, P_T > &p_s, 
   output_range < P_R, P_C > const &p_r) 
  { 
::boost ::copy 
      (p_r. m_range, 
       ::std ::ostream_iterator 
       < typename ::boost ::range_value < P_R > ::type, P_C, P_T > 
(p_s, p_r .m_sep)); 
    return p_s; }}
  template < class P_R, class P_C > 
  detail ::output_range < P_R, P_C > 
  separated (P_R const &p_r, P_C const p_s []) 
  { return detail ::output_range < P_R, P_C > (p_r, p_s); }
}

[Neil Groves]

I've gone with an implementation called "separated" as suggested but have made the Separated type a template type deduced to allow more flexibility. I also copy the iterators rather than refer to the range to avoid lifetime issues.

The original suggestion of having a prefix and suffix built into this function has been dropped since this unnecessary coupling.

This is committed to develop and will be merged for Release 1.56

[Akira Takahashi <faithandbrave@…>]

I checked the feature. Now interface is follow:

separated(v, ',')

I think better interface is follow:

v | separated(','); // pipe operator version (past participle)
separate(v, ','); // function version (present form)

More improvement interface:

v | formatted; // {a,b,c}
v | formatted(','); // {a,b,c}
v | formatted(',', '{', '}'); // {a,b,c}

[Akira Takahashi <faithandbrave@…>]

Please check my comment, Neil.

[Neil Groves]

Reimplemented as the formatted adaptor. This is committed to develop. Once the tests have cycled a few times I shall merge this to master and therefore to the next release.

[Akira Takahashi <faithandbrave@…>]

checked. It seems good design and implementation. Thanks!

[Neil Groves]

I apologise for taking so long. My ego is a little bruised from making so many poor decisions and then U-turns, but at least the end result is good.

Thanks for your patience. The code is now merged to master.