[BGL] - deriving from filtered_graph
When using a type that I derived from filtered_graph, if I use
operator[] on the instance, e.g.
derived_from_filtered_graph_instance[descriptor].foo = bar;
I get the following error:
C:\dev\vendor\boost\1.37.0\boost/graph/graph_traits.hpp(124) : error
C2039: 'edge_bundled' : is not a member of
'btra::restricted_graph<Graph>'
1> with
1> [
1> Graph=btra::undirected_graph
1> ]
1> C:\dev\vendor\boost\1.37.0\boost/graph/graph_traits.hpp(137)
: see reference to class template instantiation
'boost::edge_bundle_type<G>' being compiled
1> with
1> [
1> G=btra::restricted_graphbtra::undirected_graph
1> ]
1> C:\dev\btra\trunk\btra/two_way/esri_io.h(186) : see
reference to class template instantiation
'boost::graph::detail::bundled_result
C:\dev\vendor\boost\1.37.0\boost/graph/graph_traits.hpp(124) : error C2039: 'edge_bundled' : is not a member of 'btra::restricted_graph<Graph>' 1> with 1> [ 1> Graph=btra::undirected_graph 1> ]
and if I typedef edge_bundled in the derived class, everything seems to work okay. filtered_graph doesn't contain the typedef, the Graph type does, so does this mean that to be more correct I should specialize graph_traits for my derived type, or is just having the typedef enough?
Also, in the filtered_graph documentation, it says it models VertexAndEdgeListGraph and PropertyGraph, but neither of those concepts mention edge_bundled as an associated type.
I think reverse_graph (one of the other adaptors?) also provides a typedef for vertex_bundled and edge_bundled, so that's probably the right solution. the *_bundled typedefs are really implementation details rather than concept requirements. You'll never actually used the _bundled typedef - some of the mechanics of property access use it to decode graph properties. Andrew Sutton andrew.n.sutton@gmail.com
On Wed, Jan 28, 2009 at 7:44 AM, Andrew Sutton
the *_bundled typedefs are really implementation details rather than concept requirements. You'll never actually used the _bundled typedef - some of the mechanics of property access use it to decode graph properties.
But doesn't that mean the Concepts for property access should reflect what is actually required by a type? Or should the implementation detail not be leaked in the first place? --Michael Fawcett
But doesn't that mean the Concepts for property access should reflect what is actually required by a type? Or should the implementation detail not be leaked in the first place?
The implementation probably shouldn't be leaked, but one could argue that no implementation details are being leaked in this case. If filtered graph adaptor defines the interface/implementation boundary, then clients of the adaptor would never have to see those typedefs. Since you're deriving from the adaptor, you're not the same kind of client. You're extending the library by creating a *new* adaptor and hence, have to deal with the implementation :) Either way, it might be possible to move that logic into a metafunction that can be inherited by any adaptor and make extension a little easier. Andrew Sutton andrew.n.sutton@gmail.com
participants (2)
-
Andrew Sutton -
Michael Fawcett