Re: Boost algorithm library

From: helmut.zeisel_at_[hidden]
Date: 2001-07-26 13:39:33

--- In boost_at_y..., Jeremy Siek <jsiek_at_r...> wrote:
> On Thu, 26 Jul 2001 helmut.zeisel_at_a... wrote:
> >
> > > but this will cause a problem
> > if one
> > > wants to call this with make_range().
> > >
> > > sort_heap(make_range(first, last)); // error, binding temporary
to a
> > >                                     // reference
> > >
> >
> > I tested using VC++ :-(
> >
> > Do you have any idea how to solve this problem?
> > Passing by const reference and a const_cast within the algorithm?
> > This would be very ugly :-(
> 
> One option might be to provide two versions of the one-arg
sort_heap(),
> one that takes any container by reference, and the other that is
> explicitly overloaded for the range class.

If we have to provide two versions for the mutating
algorithms, not much will be won.
It would be the same work to add
a trivial container / range interface to the
existing 2-iterator interfaces.

Clearly the nonmutating algorithms would need only
one interface, but treating them differnetly
might be more confusing than helpful.

> 
> Another issue is that I'd like to be able to use these kinds of
functions
> with the graph library. The graph library uses functions that return
pairs
> of iterators. I want to be able to write this:
> 
> find_if(edges(g), is_residual_edge());
> 
> // edges() returns pair<edge_iterator,edge_iterator>
> 

As I understand, the semantics of this pair is a range.
A pair has been chosen because no better type
was available.
If a range class is added to boost,
it will make sense to change the return type to a range
to make the semantics obvious.

Helmut