[BGL] bad edge iterator range returned by boost::out_edges(v,g)?
This is weird... I'm still using BGL from Boost 1_29_0 (which may be an issue?). Anyway, I've got a graph as so: typedef boost::property<vertex_forest_property_t, CProteinCircuitForestVertexProperty, boost::property<boost::vertex_index_t, long, boost::property<boost::vertex_color_t, boost::default_color_type> > > forest_vertex_property_maps_declaration_t; typedef boost::adjacency_list<boost::listS /*edges*/, boost::listS /*vertices*/, boost::bidirectionalS, forest_vertex_property_maps_declaration_t> forest_graph_t; I've done a lot with this class, including all kinds of edge traversal. Now suddenly I have a case where boost::out_edges seems to be returning an invalid iterator range. I'm absolutely certain the vertex descriptor is correct, boost::out_degree returns the expected number of out edges, however I fault inside my access loop because the iterator has gone out of range.... typedef boost::graph_traits<forest_graph_t>::vertex_descriptor forest_vertex_descriptor_t; typedef boost::graph_traits<forest_graph_t>::vertex_descriptor forest_vertex_descriptor_t; typedef boost::graph_traits<forest_graph_t>::edges_size_type forest_edges_size_t; typedef boost::graph_traits<forest_graph_t>::out_edge_iterator forest_edge_out_iterator_t; forest_edge_out_iterator_t edgeoutiterBegin, edgeoutiterEnd, edgeoutiterCurrent; boost::tie(edgeoutiterBegin, edgeoutiterEnd) = boost::out_edges(v/*forest_vertex_descriptor_t*/,g/*forest_graph_t); for (edgeoutiterCurrent = edgeoutiterBegin; edgeoutiterCurrent != edgeoutiterEnd ; ++edgeoutiterCurrent) { // works fine through the expected out edges - faults because the loop fails to terminate forest_vertex_descriptor_t vertexTarget = boost::target(*edgeoutiterCurrent, g); } // end for Any suggestions would be greatly appreciated. I'm really scratching my head because I've done this exact operation in several other places in the algorithm and it works just fine.... TIA - Chris
I'm trying to use jam in place of nmake under VC6. The interesting thing is, I'm trying to use the VC7.1 compiler (I hate the new IDE). The problem is that the Path environment is hijacked by VC6 and replaced with its own idea of what the world should look like (i.e. VC6 paths). In nmake, I can do: MSDEV = C:\Program Files\Microsoft Visual Studio .NET 2003 MSVC = $(MSDEV)\VC7 CPP = "$(MSVC)\bin\cl" IDE = $(MSDEV)\COMMON7\IDE PATH = $(IDE);$(PATH) INCLUDE = $(MSVC)\Include Fred.exe: Fred.cpp $(CPP) Fred.cpp and all is well. VC7.1 runs and compiles Fred. Under jam, I can load VC7.1 but it won't run because it looks in the path for its DLLs, from the IDE, and the path isn't getting set. If I preset the path before running VC6, the VC7.1 stuff is stripped out by VC6 as it loads. Is there a way round this, or do I have to go back to nmake :-( Rob Marsden Gistix (Northern) Limited
Rob, please take your Boost.Build questions to the jamboost list. See http://www.boost.org/more/mailing_lists.htm#jamboost rmarsdena@cix.co.uk writes:
I'm trying to use jam in place of nmake under VC6. The interesting thing is, I'm trying to use the VC7.1 compiler (I hate the new IDE).
The problem is that the Path environment is hijacked by VC6 and replaced with its own idea of what the world should look like (i.e. VC6 paths).
I think what I'm hearing you say is that you're trying to use Boost.Build to build with vc++7.1 in place of nmake under VS6 ^^^ Visual C++ is a compiler Visual Studio is an IDE
In nmake, I can do:
MSDEV = C:\Program Files\Microsoft Visual Studio .NET 2003 MSVC = $(MSDEV)\VC7 CPP = "$(MSVC)\bin\cl" IDE = $(MSDEV)\COMMON7\IDE PATH = $(IDE);$(PATH) INCLUDE = $(MSVC)\Include
Fred.exe: Fred.cpp $(CPP) Fred.cpp
and all is well. VC7.1 runs and compiles Fred.
Under jam, I can load VC7.1 but it won't run because it looks in the path for its DLLs, from the IDE, and the path isn't getting set. If I preset the path before running VC6, the VC7.1 stuff is stripped out by VC6 as it loads.
Is there a way round this, or do I have to go back to nmake :-(
Make sure MSVCDir is unset in bjam and use the vc7.1 toolset. One way to do that might be: bjam -sMSVCDir= -sTOOLS=vc7.1 -- Dave Abrahams Boost Consulting www.boost-consulting.com
David, Thanks for the comments.
Visual C++ is a compiler Visual Studio is an IDE
Indeed, my woolly thinking in the heat of battle :-) I should have put VS6. I tried:
bjam -sMSVCDir= -sTOOLS=vc7.1
and used Main Fred.exe : Fred.cpp ; as a test, and that loads VC6 compiler, but does find all the dependencies in the VC7.1 include directories. If I then make the jamfile: MSDEV = "C:/Program Files/Microsoft Visual Studio .NET 2003" ; MSVC = $(MSDEV)/VC7 ; C++ = \"$(MSVC)/bin/cl\" ; Main Fred.exe : Fred.cpp ; It still finds the VC7.1 includes and this time loads the VC7.1 compiler, which immediately crashes because it can't find its DLLs. This is because the path is not properly set up for VC7.1. In fact, the path that is displayed in the error message has had all references to VC7.1 stripped out and VC6 put in their place (this can be overridden in nmake by setting the Path environment variable). So what seems to missing, is a way to set the Path in the current environment prior to running VC7.1 in the actions. Is that possible? Rob Marsden Gistix (Northern) Limited
Visual C++ is a compiler Visual Studio is an IDE
Indeed, my woolly thinking in the heat of battle :-) I should have put VS6.
I tried:
bjam -sMSVCDir= -sTOOLS=vc7.1
and used
Main Fred.exe : Fred.cpp ; ^^^^ That's a Perforce ("Classic") Jam rule, not a Boost.Build rule. You can't expect setting TOOLS to help you if you're going to use those
rmarsdena@cix.co.uk writes: primitives... and I can't be much help with Perforce Jam stuff anyway. If you want to do this, you should invoke "jam" and not "bjam", though. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Hi Dave,
If you want to do this, you should invoke "jam" and not "bjam", though.
I'm now using bjam. I have both in my path. As you may have seen elsewhere in this list, I was querying the relationship between jam and bjam. I now have the problem with not being able to spawn actions. I think it's something to do with spaces in paths, but time is running short. Rob Marsden Gistix (Northern) Limited
rmarsdena@cix.co.uk writes:
Hi Dave,
If you want to do this, you should invoke "jam" and not "bjam", though.
I'm now using bjam.
Have you given up on "Main"? Otherwise, you will be frustrated forever.
I have both in my path. As you may have seen elsewhere in this list, I was querying the relationship between jam and bjam.
jam is the same executable as bjam, but based on its name it tries to preserve backward-compatible Perforce Jam behavior. bjam executes a different part of the Jambase, so it has different built-in rules and behaviors.
I now have the problem with not being able to spawn actions. I think it's something to do with spaces in paths, but time is running short.
You should post your questions to the jamboost list; you'll get better help there. See http://www.boost.org/more/mailing_lists.htm#jamboost -- Dave Abrahams Boost Consulting www.boost-consulting.com
Once again, thanks Dave.
Have you given up on "Main"? Otherwise, you will be frustrated forever.
I've adopted the idea of developing a script from first principles, relying on nothing in jambase, as far as possible. I was reckoning on that being the only way to learn the intricacies of bjam.
You should post your questions to the jamboost list; you'll get better help there. See http://www.boost.org/more/mailing_lists.htm#jamboost
I didn't know about that list. So I'll get over there ASAP. Things will slow down now for me, as I've now got a few weeks stint on the help desk to cover for staff holidays. Rob Marsden Gistix (Northern) Limited
Hi Rob,
I'm trying to use jam in place of nmake under VC6. The interesting thing is, I'm trying to use the VC7.1 compiler (I hate the new IDE).
The problem is that the Path environment is hijacked by VC6 and replaced with its own idea of what the world should look like (i.e. VC6 paths).
Yes, the VC6 IDE sets its own paths for executeables, include, and library directories. You could configure them in the menu item "Tools" - "Options". In the dialog then go to the tab page "Directories". But this would change the paths for any project you are using. Why don't you use NMAKE _and_ jam in conjunction with the IDE? You can create a "Makefile" project in the IDE, which just calls NMAKE. In this way you can define your paths to the VC7 build environent in a Makefile:
MSDEV = C:\Program Files\Microsoft Visual Studio .NET 2003 MSVC = $(MSDEV)\VC7 CPP = "$(MSVC)\bin\cl" IDE = $(MSDEV)\COMMON7\IDE PATH = $(IDE);$(PATH) INCLUDE = $(MSVC)\Include
As target in the makefile you can define some thing like: main: bjam -f Jamfile Or yet another way - use a batch file, which defines the environment variables you need and call jam in it. You can define this batch file as "Build command line" in the project settings dialog. The IDE is very flexible. :-) Yours, Martin -- Martin Fuchs martin-fuchs@gmx.net
Martin, Thanks for the suggestion, it looks like the make file might be the answer, but I'm now stuck with another problem. I get a 'cannot spawn' error from jam. It looks like its not understanding the command line. I suspect spaces etc. What are the differences between jab and bjam? They're both on this machine. I'm just about out of time on getting jam to work, having committed �,000s to it already. Unless I get a working system by close of business Friday, it's dead in the water, and I'm onto another project, having lost a brownie point. Rob Marsden Gistix (Northern) Limited
This is weird...
I'm still using BGL from Boost 1_29_0 (which may be an issue?). Anyway, I've got a graph as so:
typedef boost::property<vertex_forest_property_t, CProteinCircuitForestVertexProperty, boost::property<boost::vertex_index_t, long, boost::property<boost::vertex_color_t, boost::default_color_type> >
forest_vertex_property_maps_declaration_t;
typedef boost::adjacency_list<boost::listS /*edges*/, boost::listS /*vertices*/, boost::bidirectionalS, forest_vertex_property_maps_declaration_t> forest_graph_t;
I've done a lot with this class, including all kinds of edge traversal. Now suddenly I have a case where boost::out_edges seems to be returning an invalid iterator range. I'm absolutely certain the vertex descriptor is correct, boost::out_degree returns the expected number of out edges, however I fault inside my access loop because the iterator has gone out of range....
typedef boost::graph_traits<forest_graph_t>::vertex_descriptor forest_vertex_descriptor_t; typedef boost::graph_traits<forest_graph_t>::vertex_descriptor forest_vertex_descriptor_t; typedef boost::graph_traits<forest_graph_t>::edges_size_type forest_edges_size_t; typedef boost::graph_traits<forest_graph_t>::out_edge_iterator forest_edge_out_iterator_t;
forest_edge_out_iterator_t edgeoutiterBegin, edgeoutiterEnd, edgeoutiterCurrent; boost::tie(edgeoutiterBegin, edgeoutiterEnd) = boost::out_edges(v/*forest_vertex_descriptor_t*/,g/*forest_graph_t); for (edgeoutiterCurrent = edgeoutiterBegin; edgeoutiterCurrent != edgeoutiterEnd ; ++edgeoutiterCurrent) { // works fine through the expected out edges - faults because the loop fails to terminate forest_vertex_descriptor_t vertexTarget = boost::target(*edgeoutiterCurrent, g); } // end for
Any suggestions would be greatly appreciated. I'm really scratching my
When in doubt: stare at the code, post a dumb question, take the huskies for a walk, come back with a theory... I think this is my own idiocy. Inside the loop I'm making a method call that removes edges. This invalidates the iterators right? "Chris Russell" <cdr@encapsule.com> wrote in message news:bbj0fu$miu$1@main.gmane.org... head
because I've done this exact operation in several other places in the algorithm and it works just fine....
TIA - Chris
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/
When in doubt: stare at the code, post a dumb question, take the huskies for a walk, come back with a theory...
I think this is my own idiocy. Inside the loop I'm making a method call
Right? Right. Dunce: one who is slow-witted or stupid "Chris Russell" <cdr@encapsule.com> wrote in message news:bbj4l1$ajl$1@main.gmane.org... that
removes edges. This invalidates the iterators right?
participants (4)
-
Chris Russell -
David Abrahams -
Martin Fuchs -
rmarsdena＠cix.co.uk