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
> > > // 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
> 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
> with the graph library. The graph library uses functions that return
> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk