[BGL] named parameter defaults and namespace confusion
In my project, I'm using several different graph objects that are declared in different namespaces. All of these graphs use default internal color maps. Suppose I declare a graph in namespace A. In another namespace, say namespace B, I attempt to invoke a DFS using the named parameter version of the call specifying only the visitor and defaulting the rest of the parameters. Specifically, I do not specify the color map in the named parameter list. What I expected was that the DFS would find, and use the default internal color map of the graph declared in namespace A. However, it appears that it does not and allocates a temporary color map (I assume the compiler searches namespace B, not A). Subsequently when DFS attempts to initialize the color map to white, a fault occurs at runtime (I haven't had time to get into the guts of DFS and figure out exactly why this bombs yet). I've worked around this by using the standard (sans named parameters) version of the DFS call (explicitly passing in a reference to the internal color map). This seeming interaction between the named parameter mechanism and namespaces is pretty subtle - if not for the runtime fault, I would likely have never noticed that the internal property map wasn't being used during the search. Has anyone else seen this? - Chris
Hi Chris, The namespaces are a red herring. If you don't explicitly supply a color map, the default for DFS is to allocate a temporary map, not to look into the graph for an internal color map. I think the reason I designed it that way is that I figured it would be more common for the user not to care about the color map, and prefer it to be taken care of by the algorithm. As for the memory fault... are your vertex indices in the range [0, num_vertices(g)) ? If not that could cause a problem. Cheers, Jeremy On Monday, August 18, 2003, at 10:13 PM, Chris Russell wrote:
parameters. Specifically, I do not specify the color map in the named parameter list. What I expected was that the DFS would find, and use the default internal color map of the graph declared in namespace A. However, it appears that it does not and allocates a temporary color map (I assume the
Sure - that makes sense. As for the vertex indices.... Hmmm.
Theoretically... I'll have to go look at the source (creation of this
particular graph is constructed by a graph algorithm analyzing another
graph, and referencing data from a third so it's entire possible I messed it
up somewhere...) But if they were screwed up wouldn't I bomb regardless of
which version of the DFS call I made?
- Chris
----- Original Message -----
From: "Jeremy Siek"
parameters. Specifically, I do not specify the color map in the named parameter list. What I expected was that the DFS would find, and use the default internal color map of the graph declared in namespace A. However, it appears that it does not and allocates a temporary color map (I assume the
Info: http://www.boost.org Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl Unsubscribe: mailto:boost-users-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
On Monday, August 18, 2003, at 10:51 PM, Chris Russell wrote:
Sure - that makes sense. As for the vertex indices.... Hmmm. Theoretically... I'll have to go look at the source (creation of this particular graph is constructed by a graph algorithm analyzing another graph, and referencing data from a third so it's entire possible I messed it up somewhere...) But if they were screwed up wouldn't I bomb regardless of which version of the DFS call I made?
Not necessarily. If VertexList=listS then the vertex_descriptor is a pointer, and dereferencing this pointer gives a struct with the color as a data member. So the vertex index is never used in that case. Cheers, Jeremy
participants (2)
-
Chris Russell -
Jeremy Siek