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
> >| 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:
- 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.
2) Simplify the algorithm signature.
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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk