[BGL] Question on dijkstra-example.cpp
Hello, could you please explain what this code in the dijkstra-example (http://www.boost.org/doc/libs/1_44_0/libs/graph/example/dijkstra-example.cpp) exactly does? predecessor_map(&p[0]).distance_map(&d[0]) I understand the non-named-parameter version, but the combination of predecessor_map with distance_map is not so obvious to me. What does the "." do there? Do I get it right, that the predecessor_map or distance_map, respectively, automatically wrap the vectors p and d into iterator_property_maps? Thank you. Best regards, Cedric
On Thu, 11 Nov 2010, Cedric Laczny wrote:
Hello,
could you please explain what this code in the dijkstra-example
(http://www.boost.org/doc/libs/1_44_0/libs/graph/example/dijkstra-example.cpp) exactly does?
predecessor_map(&p[0]).distance_map(&d[0])
I understand the non-named-parameter version, but the combination of predecessor_map with distance_map is not so obvious to me. What does the "." do there?
Do I get it right, that the predecessor_map or distance_map, respectively, automatically wrap the vectors p and d into iterator_property_maps?
The . there is separating two named parameters; the BGL named parameter mechanism uses . to separate parameters instead of , to avoid needing to have multiple overloads of each function. On your second question, there is infrastructure in BGL for pointers to be automatically treated as property maps, and so &p[0] gets a pointer that will go through this mechanism. I do not recommend writing your own code that way, though; use iterator_property_map or shared_array_property_map instead since they express your intentions better and work with more graph types. It is easy to get very subtle bugs if you use pointers as property maps in code that doesn't know the exact graph type it will be using. -- Jeremiah Willcock
participants (2)
-
Cedric Laczny
-
Jeremiah Willcock