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@rudbek.com> wrote in message news:6.1.0.6.2.20040607070211.0486b980@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