[BGL] Maps as vectors x parameterized maps
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? Thanks. -- Leandro Terra C. Melo
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
participants (2)
-
Douglas Gregor
-
Leandro Melo