RE: [boost] Re: What is the status of Container algorithms in san dbox

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2003-05-13 14:25:25

Alisdair Meredith wrote:
> I see the range concept as being of tremendous value once we start 
> using iterator adapters more frequently.  

It is. Being able to directly pass the result of one sequence algorithm
to another and to transform/filter it in the between is what functional
programming with STL is about, and that's what you cannot do with the 
standard library containers/algorithms in their current form. 

But presence of range iterator adaptors, or, as we call them here at 
Meta, sequences views, only highlights the issue. One can easily 
demonstrate the deficiency of taking two separate iterators parameters 
on the current std components; they simply don't work together well. 
Compare, for instance

std::pair<record_iterator,record_iterator> sel = selection();
std::pair<record_iterator,record_iterator> mismatching_part =
    std::mismatch( sel.first, sel.second, old_selection.begin() );
std::vector<record> v( mismatching_part.first, mismatching_part.second );

with how we can write the above here at work:

mtn::vector<record> v(
      mtn::mismatch( selection(), mtn::begin(old_selection) )
    );

> eg. filter_adapter is more clearly expressed as a range filter than a 
> single iterator.  If Dave / Jeremy / Thomas / Thorsten are happy I 
> would like to propose the range concepts and overloads for the next 
> ISO meeting (overenthusiastic new boy syndrome!) but given the TR 
> deadlines don't see how much progress I can make without tacking it 
> onto the back of an existing proposal (such as iterator adaptors)

I would say that it's iterator adaptors that depend on whether one is 
going to push forward sequence-enabled algorithms/containers, not the
opposite.

> 
> Of course as a boost library there is no such deadline, and it is 
> more a matter of community interest.
>
> I am quite keen to do the work on both counts <g> but don't want to 
> jump over people already doing this work.  If those committee members
> reading the group want to comment, I am quite happy to work on a paper
> for Kona if thought worthwhile.

I am not aware of anyone moving it forward on the standard side, and 
personally that's my primary interest on the subject. I do believe we
have enough real-world experience with it to be sure that we got the 
technical side right, and we are willing to spend some resources to
make it available for that purpose, if there is somebody who is 
determined to drive the whole thing up to the end.

Aleksey