Subject: Re: [boost] [Graph] iterator range splitting
From: Andrew Sutton (andrew.n.sutton_at_[hidden])
Date: 2008-12-17 08:38:30
> Yes, but a transform is not necessarily a projection.
> > typedef adapted_iterator<C::iterator> iterator;
> > make_pair(iterator(C.begin()), iterator(C.end())) ==
> > make_pair(iterator(C.begin()), iterator(C.end()))
> That was my initial instinct, too. but Tim is pointing out that the
> algorithms can all be raised to a higher level of generality without
> loss of efficiency, and I am now inclined to agree that there's no
> reason they need to reply on this property.
Good point. I concede :)
I think this property is still valid in many cases - and I think the
expected behavior of range-generating functions. I suppose this could be
defined as a concept, but I'm not sure how many templates take
range-generating functions as parameters. Probably none in the BGL.
That's not the patch I (or Tim, I think) had in mind. I'm talking
> about changing the algorithms so they no longer rely on
> out_edges(u,g) == out_edges(u,g) and updating the documentation to make
> it completely clear that the property just stated is not part of the
> concept requirements.
I know, but it was mentioned. It might also be better applied in cases where
an iterator from the range is discarded.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk