Modify

Opened 7 years ago

Closed 3 years ago

#4454 closed Feature Requests (fixed)

iterator range output format, and for IO adaptor

Reported by: Akira Takahashi <faithandbrave@…> Owned by: neilgroves
Milestone: Boost 1.56.0 Component: range
Version: Boost 1.44.0 Severity: Problem
Keywords: Cc:

Description

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

Attachments (1)

range_io.zip (4.4 KB) - added by Akira Takahashi <faithandbrave@…> 7 years ago.
source file, and test.

Download all attachments as: .zip

Change History (13)

Changed 7 years ago by Akira Takahashi <faithandbrave@…>

source file, and test.

comment:1 Changed 7 years ago by 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

comment:2 Changed 7 years ago by neilgroves

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

comment:3 Changed 7 years ago by neilgroves

  • Status changed from new to assigned

comment:4 Changed 6 years ago by giecrilj@…

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

comment:5 Changed 6 years ago by 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); }
}

comment:6 Changed 3 years ago by neilgroves

  • Milestone changed from Boost 1.44.0 to Boost 1.56.0

comment:7 Changed 3 years ago by neilgroves

  • Resolution set to fixed
  • Status changed from assigned to closed

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

comment:8 Changed 3 years ago by 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}

comment:9 Changed 3 years ago by Akira Takahashi <faithandbrave@…>

  • Resolution fixed deleted
  • Status changed from closed to reopened

Please check my comment, Neil.

comment:10 Changed 3 years ago by neilgroves

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.

comment:11 Changed 3 years ago by Akira Takahashi <faithandbrave@…>

checked. It seems good design and implementation. Thanks!

comment:12 Changed 3 years ago by neilgroves

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

Add Comment

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain neilgroves.
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.