Question

(Apologies for the title, I couldn't come up with a good one shorter than 140 characters...)

I'm writing a graph algorithm for the boost::graph library. Within my algorithm, I need to keep variables, weights and counters, about the nodes. The typical way to do this, as far as I can tell from documentation and looking at other people's code, would be to attach these properties to the graph directly and access them with property maps.

In a library function however, I don't want to require a specific read/write-map to be bundled with the graph, so I create my own external property maps. But these require a std::map (or equivalent), so I end up creating both a std::map and a boost::associative_property_map<std::map>. The good thing about this is that I have a uniform way of getting both my algorithm's properties and the user's properties (boost::get), but on the downside, I seem to have two redundant maps. Is there any meaning in doing this besides mentioned uniformity? Can I somehow let the property map maintain it's own internal map (I realize there would be no gain in memory etc, but there would be one less member variable to keep track of per property)?

Was it helpful?

Solution

In a nutshell, create a map m and an associative property map pm using m and you won't generate a redundancy. More information follows.

boost::associative_property_map does not create a new map. It only references another map and makes it accessible through the boost property_map API (get & put).

See the documented example here.

If you go and have a look at the constructor for associative_property_map, you'll see that it takes a reference to a container and stores its address as a pointer (m_c). Look here and search the file for "associative_property_map".

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top