David Abrahams wrote:
Thorsten Ottosen <tottosen@dezide.com> writes:
David Abrahams wrote:
Thorsten Ottosen <tottosen@dezide.com> writes:
For that drop_front works great.
how do you construct the range [begin,found) if the algorithm returns ther range [found,end) ?
Maybe you just write an algorithm for that?
There are lots of ways to approach this. Maybe you want an uber-find that returns a quadruple of iterators from which you can choose:
^^^^^^^^^^^^^^^^^^^^^^^^
uber_find( x, 5 ).range(0,2);
or
uber_find( x, 5 ).range(_0,_2);
that is, it grabs the 0th (beginning) and 2nd (after-found-element) iterators from the result.
That can just be a member function in iterator_range<T>, eg slice(size_type,size_type).
No, that's not the same thing at all. Read what I wrote again.
ok, so we could return a tripple {begin,found,end}. this means that 1. we loose the benefit of a default 2. a slight overhead (the tripple construction cannot be optmized away) 3. at least as complicated an implementation
Anyway, if the convention of range-based algorithms should be "always return [found,end)", it raises the question why we think this range is more imoprtant than [begin,found) (and some of the others).
The natural answer is of course: it is not more important or more fundamental.
Therefore it is natural to investigates means to return the slices you need. We have already seen that seperate slice functions cannot be always be safe unless they require the use of a temporary, thus defeating the much purpose of ranges.
I'm sure you must mean a named intermediate value, not a temporary.
right. I couldn't find the definition of "temporary" in the standard; is it defined and inherted from C?
It also illustrates that if we change the template parameter to a function parameter, pack() becomes a big function with a switch case.
I don't see it. It looks like my function is a new overload of find.
well, you have to decide which range to construct based on the indexes passed to the algorihtm.
Sounds easy enough to do without a switch. And anyway, who cares about such a tiny implementation detail?
nobody unless it affects the generated code size/speed. -Thorsten