Boost C++ Libraries: Ticket #4454: iterator range output format, and for IO adaptor

attachment set

Tue, 20 Jul 2010 05:21:42 GMT

attachment → range_io.zip

source file, and test.

Tue, 20 Jul 2010 05:34:56 GMT

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 — Thu, 22 Jul 2010 20:22:53 GMT

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

status changed

Neil Groves — Sun, 14 Nov 2010 17:47:53 GMT

status new → assigned

giecrilj@… — Mon, 12 Dec 2011 01:09:37 GMT

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

giecrilj@… — Mon, 12 Dec 2011 02:35:13 GMT

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

milestone changed

Neil Groves — Tue, 04 Mar 2014 13:02:45 GMT

milestone Boost 1.44.0 → Boost 1.56.0

status changed; resolution set

Neil Groves — Sun, 09 Mar 2014 21:19:07 GMT

status assigned → closed
resolution → fixed

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

Mon, 10 Mar 2014 05:48:25 GMT

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}

status changed; resolution deleted

Mon, 24 Mar 2014 02:15:53 GMT

status closed → reopened
resolution fixed

Please check my comment, Neil.

Neil Groves — Thu, 05 Jun 2014 00:06:35 GMT

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.

Thu, 05 Jun 2014 04:58:36 GMT

checked. It seems good design and implementation. Thanks!

status changed; resolution set

Neil Groves — Thu, 05 Jun 2014 13:48:42 GMT

status reopened → closed
resolution → fixed

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.