[graph] ranges used by boost.graph not compatible with c++11 range-based-for

newer
[graph] ranges used by boost.graph...

Gabriel Redner

2 Oct 2013 2 Oct '13

8:46 p.m.

I noticed today that code of this form does not compile: typedef boost::adjacency_list Graph; typedef boost::graph_traits<Graph>::vertex_descriptor Vertex; typedef boost::graph_traits<Graph>::edge_descriptor Edge; Graph graph = ...; Vertex vertex = ...; for (Edge edge: boost::out_edges(vertex, graph)) {...} The reason is that out_edges returns a std::pair of iterators. This is a valid range in the sense of boost.range, and so is compatible with BOOST_FOREACH. However, this is not a valid range in the sense of c++11 range-based-for. It's not clear whether this can easily be changed. In a perfect world these functions should probably return something like boost::iterator_range which would be compatible with both boost- and language-level concepts of range-ness. However, the graph documentation explicitly names the return types of out_edges et. al. (see [1]) as std::pairs, which eliminates some wiggle room. Is there an alternate way to address this? -Gabe [1] http://www.boost.org/doc/libs/1_53_0/libs/graph/doc/IncidenceGraph.html

Show replies by date

Jeremiah Willcock

2 Oct 2 Oct

8:51 p.m.

New subject: [graph] ranges used by boost.graph not compatible with c++11 range-based-for

On Wed, 2 Oct 2013, Gabriel Redner wrote:

...

I noticed today that code of this form does not compile:

typedef boost::adjacency_list Graph; typedef boost::graph_traits<Graph>::vertex_descriptor Vertex; typedef boost::graph_traits<Graph>::edge_descriptor Edge; Graph graph = ...; Vertex vertex = ...; for (Edge edge: boost::out_edges(vertex, graph)) {...}

The reason is that out_edges returns a std::pair of iterators. This is a valid range in the sense of boost.range, and so is compatible with BOOST_FOREACH. However, this is not a valid range in the sense of c++11 range-based-for.

It had been allowed in range-based for previously, but was removed before C++11 was released.

...

It's not clear whether this can easily be changed. In a perfect world these functions should probably return something like boost::iterator_range which would be compatible with both boost- and language-level concepts of range-ness. However, the graph documentation explicitly names the return types of out_edges et. al. (see [1]) as std::pairs, which eliminates some wiggle room. Is there an alternate way to address this?

I'm not sure. There might be a way to inherit from std::pair to be compatible while still allowing range-based for, but I am not sure. Another option would be a wrapper that converted an std::pair to a range. -- Jeremiah Willcock

Nathan Ridge

8:57 p.m.

New subject: [graph] ranges used by boost.graph not compatible with c++11 range-based-for

...

I noticed today that code of this form does not compile:

typedef boost::adjacency_list Graph; typedef boost::graph_traits<Graph>::vertex_descriptor Vertex; typedef boost::graph_traits<Graph>::edge_descriptor Edge; Graph graph = ...; Vertex vertex = ...; for (Edge edge: boost::out_edges(vertex, graph)) {...}

The reason is that out_edges returns a std::pair of iterators. This is a valid range in the sense of boost.range, and so is compatible with BOOST_FOREACH. However, this is not a valid range in the sense of c++11 range-based-for.

It's not clear whether this can easily be changed. In a perfect world these functions should probably return something like boost::iterator_range which would be compatible with both boost- and language-level concepts of range-ness. However, the graph documentation explicitly names the return types of out_edges et. al. (see [1]) as std::pairs, which eliminates some wiggle room. Is there an alternate way to address this?

Sadly, I don't think there s a way of turn an std::pair of iterators into a range-based-for-compliant range (see [1]). So, I think that if Boost.Range wants to interoperate with standard ranges, it will need to deprecate std::pair of iterators as a range, and dependent libraries will need to follow suit. Regards, Nate [1] http://stackoverflow.com/questions/6167598/why-was-pair-range-access-removed...

Marshall Clow

3 Oct 3 Oct

2:08 p.m.

On Oct 2, 2013, at 1:57 PM, Nathan Ridge wrote:

...

...
I noticed today that code of this form does not compile:

typedef boost::adjacency_list Graph; typedef boost::graph_traits<Graph>::vertex_descriptor Vertex; typedef boost::graph_traits<Graph>::edge_descriptor Edge; Graph graph = ...; Vertex vertex = ...; for (Edge edge: boost::out_edges(vertex, graph)) {...}

The reason is that out_edges returns a std::pair of iterators. This is a valid range in the sense of boost.range, and so is compatible with BOOST_FOREACH. However, this is not a valid range in the sense of c++11 range-based-for.

It's not clear whether this can easily be changed. In a perfect world these functions should probably return something like boost::iterator_range which would be compatible with both boost- and language-level concepts of range-ness. However, the graph documentation explicitly names the return types of out_edges et. al. (see [1]) as std::pairs, which eliminates some wiggle room. Is there an alternate way to address this?

Sadly, I don't think there s a way of turn an std::pair of iterators into a range-based-for-compliant range (see [1]).

So, I think that if Boost.Range wants to interoperate with standard ranges, it will need to deprecate std::pair of iterators as a range, and dependent libraries will need to follow suit.

Regards, Nate

[1] http://stackoverflow.com/questions/6167598/why-was-pair-range-access-removed...

Actually, it's pretty simple: http://cplusplusmusings.wordpress.com/2013/04/14/range-based-for-loops-and-p... -- Marshall Marshall Clow Idio Software mailto:mclow.lists@gmail.com A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

Nathan Ridge

3:25 p.m.

New subject: [graph] ranges used by boost.graph not compatible with c++11 range-based-for

...

Actually, it's pretty simple: http://cplusplusmusings.wordpress.com/2013/04/14/range-based-for-loops-and-p...

That just looks like a pared-down version of iterator_range. How does it solve the backward compatibility problem? Regards, Nate

4072

Age (days ago)

4073

Last active (days ago)

List overview

Download

4 comments

4 participants

participants (4)

Gabriel Redner
Jeremiah Willcock
Marshall Clow
Nathan Ridge