Re: [boost] [Graph] iterator range splitting

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.

Andrew Sutton
andrew.n.sutton_at_[hidden]