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):
> >> https://svn.boost.org/trac/boost/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
> http://www.boost.org/doc/libs/1_47_0/libs/graph/doc/VertexListGraph.html).
Thanks for the advice. I read the document. My understanding is that
concept check's purpose is to constrain the custom containers.
e.g.
http://www.boost.org/doc/libs/1_47_0/libs/graph/doc/using_adjacency_list.html#sec:custom-storage
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.
Hmm...
Should we only rely on MultiPassInputIterator capability?
Thanks,
Takatoshi