Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2006-02-03 19:38:24

Thorsten Ottosen <tottosen_at_[hidden]> writes:

> David Abrahams wrote:
>> Thorsten Ottosen <tottosen_at_[hidden]> 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.

> 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.

>>>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?

Dave Abrahams
Boost Consulting

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