|
Boost Users : |
From: Douglas Gregor (doug.gregor_at_[hidden])
Date: 2006-08-18 15:41:30
On Aug 17, 2006, at 6:56 AM, Leandro Melo wrote:
> Hi!
> Some of boost algorithms require a vertex_index_map. Since I'm not
> very familiar with bgl, I don't know if there're any which also
> require an edge_index_map. If the algorithms were parametrized by the
> above maps, we could use vectors indexed by the the values in this
> maps to create capacity_maps, distance_maps, weight_maps and any other
> maps required by the algorithm (however, to maintain the same level of
> flexibility we would have to allow the users to parameterize the value
> types of this vectors). And we would still have constant time access
> to the maps (like the default boost map implementations in the
> algorithms).
> Just for a matter of curiosity, what are advantages between using
> boost's strategy and the one I described above (in which all maps
> would be vectors)?
> The major benefit I can see on boost's current strategy is
> flexibility. The user can use any map implementation he/she wants
> (maybe this maps comes from legacy applications). There's also the
> possibility of implementing readable and writable maps.
> What are others advantages? And what could be the drawbacks of using
> this vector aproach?
I think you've already mentioned the most important benefit. By
making property maps completely abstract, they can map to any kind of
data. The vector approach you are describing is actually done
internally, when BGL algorithms need to create a property map
internally. We typically use iterator_property_map (pointing into a
vector) or vector_property_map (actually uses a vector, directly).
Doug
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net