Modifying bundled properties from visitor

Question

How should I modify the bundled properties of a vertex from inside a visitor?

I would like to use the simple method of sub-scripting the graph, but the graph parameter passed into the visitor is const, so compiler disallows changes.

I can store a reference to the graph in the visitor, but this seems weird.

/**

  A visitor which identifies vertices as leafs or trees

*/
class bfs_vis_leaf_finder:public default_bfs_visitor {

public:
    /**

    Constructor

    @param[in] total reference to int variable to store total number of leaves
    @param[in] g reference to graph ( used to modify bundled properties )

    */
    bfs_vis_leaf_finder( int& total, graph_t& g ) :
      myTotal( total ), myGraph( g )
      {
          myTotal = 0;
      }

    /**

    Called when the search finds a new vertex

    If the vertex has no children, it is a leaf and the total leaf count is incremented

    */
    template <typename Vertex, typename Graph>
    void discover_vertex( Vertex u, Graph& g)
    {
        if( out_edges( u, g ).first == out_edges( u, g ).second ) {
            myTotal++;
            //g[u].myLevel = s3d::cV::leaf;
            myGraph[u].myLevel = s3d::cV::leaf;
        } else {
            //g[u].myLevel = s3d::cV::tree;
            myGraph[u].myLevel = s3d::cV::tree;
        }
    }

    int& myTotal;
    graph_t& myGraph;
};

Answer 1

Your solution is right.

To decouple the graph type from the visitor you could pass only the interesting property map to the visitor constructor and access its elements using boost::get(property, u) = s3d::cV::leaf;. This way you can pass any type-compatible vertex property to the visitor (the visitor will be more general and not sensible to name changes in the graph type).

The type for the property map will be a template type-name for the visitor class and will be something like:

typedef property_map<graph_t, s3d_cv3_leaf_t your_vertex_info::*>::type your_property_map;

See here for a complete dissertation about bundled properties.

HTH

Answer 2

I'm just learning this stuff, but I think it is correct that you must store a reference to the graph in the visitor. I'm not sure if it's for this reason, but it may be because they didn't want to provide two versions of all of the functions/require derivatives to provide two versions of each function. Especially when the pass in the graph workaround is available.

Even if it feels weird, I think passing in a reference to the graph may be the "right way".