Re: [boost] Boost.RangeEx: contains?

Subject: Re: [boost] Boost.RangeEx: contains?
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2009-02-23 17:30:09

Eric Niebler skrev:
> 
> Thorsten Ottosen wrote:

Then, other return ranges could be specified in this EDSL as
>>
>>   boost::find[_f+_1,e_]( rng | filtered );
>>   boost::find[_f-_1,e_]( rng | filtered );
>>   boost::find[_b,_f+_1]( rng | filtered );
>>   boost::find[_b,_f]( rng | filtered );
>>   boost::find[_b,_f+_1]( rng | filtered );
> 
> Interesting! That's really not half bad.
> 
>> and perhaps even allow
>>
>>   boost::find[_b+_next(n),_f]( rng | filtered );
> 
> Whoa. That could make it too easy to create invalid ranges, but way to 
> think outside the box!

Yeah, implementing e.g.

   boost::find[_f+_1,_e]( rng | filtered );

is easier because we only the expression

   _f+_1,_e

to generate a type. With

   _b+_next(n),_f

it would be a type and an embedded number.

Notice, however, that one major motivation
to let this knowledge be known to the algorithm
is, perhaps surprising, that it makes it almost
impossible to form invalid ranges --- something that
is quite easy otherwise. The cannonical example is
already in Neil's docs: """

For example, consider how easy we may erase the duplicates in a sorted 
container:

             std::vector<int> vec = ...;
             boost::erase( vec, boost::unique<boost::return_found_end>( 
boost::sort(vec) ) );

Notice the use of boost::return_found_end. What if we wanted to erase 
all the duplicates except one of them? In old-fashioned STL-programming 
we might write

             // assume 'vec' is already sorted
             std::vector<int>::iterator i = std::unique( vec.begin(), 
vec.end() );

             // remember this check or you get into problems
             if( i != vec.end() )
               ++i;

             vec.erase( i, vec.end() );

The same task may be accomplished simply with

             boost::erase( vec, 
boost::unique<boost::return_next_end>(vec) );

"""

Now, as for the possibility that

   _b+_next(n),_f-_prev(m)

would generate invalid ranges, then I guess that is true.
But the algorithm should easily be able to catch this with an assertion.
If you adjusted the range manually, afterwards, you would have the
same possibility to generate invalid ranges and not get the assertion
that the library provides (of course, the debug-iterators might catch 
this, if your library supports them).

-Thorsten