Boost logo

Boost :

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
> >
> >| 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");
     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.



Boost list run by bdawes at, gregod at, cpdaniel at, john at