Re: [boost] Re: Re: token_iterator comments, suggestions

From: Pavol Droba (droba_at_[hidden])
Date: 2004-06-07 11:37:52

On Mon, Jun 07, 2004 at 08:37:48AM -0700, Victor A. Wagner Jr. wrote:
> At Monday 2004-06-07 07:26, you wrote:
> >"Victor A. Wagner Jr." <vawjr_at_[hidden]> wrote in message 
> >news:6.1.0.6.2.20040607070211.0486b980_at_mail.rudbek.com...
> >| I disagree.
> >
> >with what? It's hard to know when you top-post :-(
> >
> >| specifically I belive we should take the time to write the syntactic 
> >sugar
> >| which allows ALL of the current algorithms to accept range<>s (that's the
> >| plural of range<>, not some variable "s").
> >
> >I can't figure out what that has to do with the discussion :-) I too like 
> >range version of
> >std::copy() etc. To recap, I'm saying
> >
> >pair<iterator,iterator> foo( iterator, iterator );
> >
> >in its range version  should be
> >
> >range< Range > foo( Range& );
> 
> Range foo(Range const&);   // is perhaps this what you meant? or perhaps:
> Range foo(Range);
> 
> I'm somewhat confused as I'd expected
> typedef pair<iterator, iterator> Range;
> to be the definition preceding your declaration of  foo(...);
> I'm not sure what a  range<Range>  would be
> 
> 
> >and not
> >
> >iterator_range< typename iterator_of<Range>::type > foo( Range& );
> >
> >Pavol disagrees, that makes the situation a 1 against 1 until other people
> >start having an opinion.
> >

There is a need to eliminate a confusion. We had a private discussion with Thorsten,
and the summary is here:

A problem: 
- Find algorithms have somewhat complicated return value. They return 
  iterator_range< typename result_iterator_of<Range>::type >.

  There are two issues regarding this:
  1) How to efectively store the result. Now the user must type rather complicated variable type.
     (i.e. iterator_range<string::iterator>)

  2) Simplify the algorithm signature.

- Suggestions

a) Thorsten is proposing to define another iterator_range-like class that will have different signature:
   range<Range>. It should generaly provide automatic iterator deduction based on Range parameter.
   Then to use this class as a return value for find algorithms

b) I think, that it is important to solve the issue 1) but the issue 2) is only cosmetic
   and a change would have several implication on the consitency of the overal library desing.

   To solve the issue 1) I suggest to define the class that Thorsten proposed. I would call it
   sub_range<T>. Name rationale is that it delimits a sub-part of a range defined by type T.
   It will be a simple derivate of iterator_range. It will have some convinient constructors.
   Both classes should be convertible to each other.
   
   So it will be possible to write:
     sub_range<string> r=find_first(str, "hello");
   or
     sub_range<const string> r=find_first(str, "hello");
 

   In addition, it seems reasonable to allow impliciti conversion of iterator_range to tuple<iterator,iterator>,
   as Thorsten suggested. So you can write:
   tie(iterator,iterator) = find_first(...);
  
   In addition to sub_range, other variants like reverse_sub_range can be defined.

Regards,

Pavol