Boost logo

Boost :

Subject: Re: [boost] [iterator] counting_iterator and reverse iterator problem (was: [graph][iterators] csr graph and reverse iterator problem)
From: Takatoshi Kondo (kondo_at_[hidden])
Date: 2011-09-09 05:02:27

On Thu, 8 Sep 2011 14:31:10 -0400 (EDT)
Jeremiah Willcock <jewillco_at_[hidden]> wrote:

> On Thu, 8 Sep 2011, Takatoshi Kondo wrote:
> > Hi,
> >
> > On Thu, 8 Sep 2011 07:48:01 +0900
> > Michel Morin <mimomorin_at_[hidden]> wrote:
> >
> >> Relevant ticket (#2640):
> >>
> >> Legal forward iterators cannot store their referents
> >> (was: counting_iterator::reference lifetime tied to iterator)
> >
> > Thanks, I've understood what is the problem.
> > I think that when we write a generic algrithm using reverse_iterator
> > or make own iterator using counting_iterator, we should refer to this
> > problem in comment.
> >
> > Anyway my problem has solved. Thanks again :)
> One further note -- there is nothing in the BGL requirements that states
> that vertex_iterators need to be bidirectional, so you cannot rely on that
> being true for arbitrary graph types (see

Thanks for the advice. I read the document. My understanding is that
concept check's purpose is to constrain the custom containers.

If the custom container doesn't satisfy the concept, compile error would occur.
I believe when I choose the container that has random access iterator for VertexList,
I can rely on the function vertices(g) returns a pair of random access iterator.
Am I wrong?

But in the case of compressed_sparse_row_graph, we can't pass
the template parameter as a container selector.The iterator's
capability depend on implementation. But it's detail of implementation.

Should we only rely on MultiPassInputIterator capability?


Boost list run by bdawes at, gregod at, cpdaniel at, john at