|
Boost : |
Subject: Re: [boost] Boost.RangeEx: contains?
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2009-02-23 13:20:36
Mathias Gaunard skrev:
> Eric Niebler wrote:
>
>> And that's my point exactly. I feel that this:
>>
>> boost::find( rng | filtered(pred) )
>>
>> is more obscure than this:
>>
>> boost::find_if( rng, pred );
>>
>> Not only that, but I presume their return types are different, too.
>> The first would return filtered iterators, the second the original
>> iterators. Isn't that right?
>
> Indeed.
>
> Which is why I suggested that boost::find return a [it, end[ range,
> rather than just the `it' iterator.
I was of the impression that find() already returned a range, like
unique(). Or is the default just different?. IMO, most algorithms
returning a single iterator would benefit from this, but I guess we
might need to discuss each algorithms in
isolation to be sure.
> That way you can do
>
> boost::empty(boost::find(rng | filtered(pred)));
>
> instead of
>
> auto rng2 = rng | filtered(pred);
> boost::find(rng2) != boost::end(rng2);
That would be find with me. I guess the crucial qustion is:
- is the main purpose of std::find() to locate an element for the purpose of
a. test containment
b. partition the sequence somehow
c. use the element
For cases a. and b., a range return would be fine. For c. a single
iterator would be best.
As for the different return type, then calling .base() should not be too
bad:
iterator i = boost::find<return_found>( rng | filtered( pred ) ).base().
But this is still not as elegant as the find_if() overload. I'm
wondering if the correct return type can somehow be inferred, or
if we can define another adaptor that unwraps some arbitrary
expression to the inner most iterators, or to some level defined by the
user:
iterator i = boost::find( rng | reversed | filtered( pred ) )
| unwrapped(2); // or just "| unwrapped"
Having to name range return type would be slightly wierd
iterator_range<iterator> r = find( rng | filtered( pred ) )
| unwrapped;
but doable.
-Thorsten
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk