[Ranges] result for range::find() (and similar)
dietmar.kuehl at gmail.com
Tue Jan 8 01:06:43 CET 2013
> On 7 Jan 2013, at 22:55, Sean Parent <sean_parent at mac.com> wrote:
> On Mon, Jan 7, 2013 at 2:20 PM, Dietmar Kuehl <dietmar.kuehl at gmail.com> wrote:
>> On 7 Jan 2013, at 20:25, Andrei Alexandrescu <andrei at erdani.com> wrote:
>> > As has been stated there are advantages and disadvantages to be had from
>> > dealing away with iterators. The way I see thing is, this decision
>> > influences direction dramatically:
>> Of course. In particular:
>> > * Iterator-based ranges are a helper for iterators
>> If ranges and iterators coexist, they need to be able to interact. Even without bringing
>> up my vision for accessing data ranges/sequences, yet (i.e., property maps), you'll get
>> a combinatorial explosion on how to call algorithms, e.g.:
>> mismatch(range0, range1)
>> mismatch(range0, begin1, end1);
>> mismatch(begin0, end0, range1);
>> mismatch(begin0, end0, begin1, end1); // yes, STL doesn't use end1; it is wrong!
> It's a different algorithm - don't make me pay for your algorithm to do additional tests if I can ensure it isn't necessary. Feel free to propose a new form of mismatch that take two ranges. There are many such algorithms.
I think it is just one algorithm but there is a bit of missing context: When I'm thinking about
STL-like algorithm I'm thinking of mixed type begin and end indicators (or single-pass and
multi-pass sequences; for bidrectional and random-access requirements the ends need to
be homogenous). That is, if you know which range is bigger, make the end unreachable,
i.e., the comparison between the end and the iterator a constexpr operator==() always
returning false. An incomplete write-up of ideas how to improve the STL is at
> By I don't know why interop implies you need all forms - I can always construct a range from a pair of iterators and I can always extract an iterator from a range.
I have trouble deciding which ranges would be passed by pairs of iterators and which
would be passed by ranges. Allowing all combinations side steps the question.
> Does anyone on this list actually have stats on how often iterators cause problems by overrunning a range that would have been caught by pessimization? I've seen many cases of people overrunning a range because they failed to supply a strict-weak-ordering to sort, or when they unknowingly invalidated their iterators, or failed to check for first==last. I cannot see recall seeing a single instance where someone overran a range where simply having a range based interface would have helped (not that a range class alone doesn't help with checking first==last unless you impose a test on every "drop_front/back" operation).
> Positions are a natural concept - I see many benefits in a great range library but only complication if it's done while trying to eliminate iterators.
I'm exploring an area where I see problems with not having iterators. If these problems
can be resolved in a reasonable way I'm happy to go along and see if a range-only
library is easier to use. If not, I'm going back and pursue the direction in which I was
experimenting before (see the link above).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ranges