Boost logo

Boost :

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


to generate a type. With


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

             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() )

             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


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


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