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

From: Thorsten Ottosen (tottosen_at_[hidden])
Date: 2006-02-04 10:05:31

David Abrahams wrote:
> 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.

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