Re: [boost] [Range] initial feedback on return values of algorithms

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
www.boost-consulting.com