Boost::Graph --- why does this program not compile?
Hello, in parallel to trying to get 1_34_1 compiling again, I'll also try to understand why the code won't compile with 1_37_0. Now I found the following program which actually compiles neither with 1_34_1 nor with 1_37_0, but it should: ------------------- #include <utility> #include <vector> #include <boost/graph/adjacency_list.hpp> template <class Graph> inline Graph orthogonality_relation() { typedef std::pair<unsigned int, unsigned int> edge_type; std::vector<edge_type> ev; Graph g(ev.begin(), ev.end(), 0, 0); return g; } typedef boost::adjacency_list<boost::listS, boost::vecS, boost::undirectedS> UndirectedGraph; int main () { orthogonality_relation<UndirectedGraph>(); } ------------------- The abbreviated error-message from gcc (version 4.1.2) is: Error.cpp:17: instantiated from here Boost/1_37_0+4.1.2/include/boost-1_37_0/boost/graph/detail/adjacency_list.hpp:2113: error: invalid type argument of ‘unary *’ where line 17 is the last line of the main-function. Oliver
template <class Graph> inline Graph orthogonality_relation() { typedef std::pair<unsigned int, unsigned int> edge_type; std::vector<edge_type> ev; Graph g(ev.begin(), ev.end(), 0, 0); return g; }
typedef boost::adjacency_list<boost::listS, boost::vecS, boost::undirectedS> UndirectedGraph;
Its probably a collaboration of problems between the pair<unsigned, unsigned> and the listS in the adjacency list. It looks like the graph is expecting a vertex descriptor to be a pointer (hence the unary *), but it's getting an unsigned (which can't be dereferenced). Try changing listS to vecS and see if that fixes the problem. Andrew Sutton andrew.n.sutton@gmail.com
Changing listS to vecS doesn't change anything. However, changing Graph g(ev.begin(), ev.end(), 0, 0); to Graph g(ev.begin(), ev.end(), 0); makes it compile (which is not a possibility in my case, since I need the optional argument). Oliver On Wed, Jan 28, 2009 at 06:38:10PM -0500, Andrew Sutton wrote:
template <class Graph> inline Graph orthogonality_relation() { typedef std::pair<unsigned int, unsigned int> edge_type; std::vector<edge_type> ev; Graph g(ev.begin(), ev.end(), 0, 0); return g; }
typedef boost::adjacency_list<boost::listS, boost::vecS, boost::undirectedS> UndirectedGraph;
Its probably a collaboration of problems between the pair<unsigned, unsigned> and the listS in the adjacency list. It looks like the graph is expecting a vertex descriptor to be a pointer (hence the unary *), but it's getting an unsigned (which can't be dereferenced). Try changing listS to vecS and see if that fixes the problem.
Andrew Sutton andrew.n.sutton@gmail.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
However, changing
Graph g(ev.begin(), ev.end(), 0, 0);
to
Graph g(ev.begin(), ev.end(), 0);
makes it compile (which is not a possibility in my case, since I need the optional argument).
It looks like the wrong constructor was instantiated. It looks like that first 0 is being substituted as an EdgePropertyIterator instead of the number of vertices, which I'm guessing is what you really want to do. If you're trying to set that last 0 as the number of edges, you don't *really* need that parameter. The constructor doesn't actually use it. It doesn't even give the parameter a name. The reason is that the iterator range defines the number of vertices. So, from what I can tell (assuming that I'm reading your intent correctly), the change that works will actually fix your problem. The other way to fix it might be: Graph g(ev.begin(), ev.end(), 0, 0, Graph::graph_property_type()); Again though, that last 0 doesn't do anything. Andrew Sutton andrew.n.sutton@gmail.com
On Fri, Jan 30, 2009 at 07:56:30AM -0500, Andrew Sutton wrote:
However, changing
Graph g(ev.begin(), ev.end(), 0, 0);
to
Graph g(ev.begin(), ev.end(), 0);
makes it compile (which is not a possibility in my case, since I need the optional argument).
It looks like the wrong constructor was instantiated. It looks like that first 0 is being substituted as an EdgePropertyIterator instead of the number of vertices, which I'm guessing is what you really want to do. If you're trying to set that last 0 as the number of edges, you don't *really* need that parameter. The constructor doesn't actually use it. It doesn't even give the parameter a name. The reason is that the iterator range defines the number of vertices.
I guess you mean the number of edges here.
So, from what I can tell (assuming that I'm reading your intent correctly), the change that works will actually fix your problem.
This works now; thanks! Shouldn't one then update the documentation? For the first constructor of adjacency_list (in the documentation), the parameters edges_size_type m = 0, const GraphProperty& p = GraphProperty()) aren't explained, and at least m isn't used, and actually seems harmful? The second constructor even has vertices_size_type m = 0, const GraphProperty& p = GraphProperty()) where likely it should be edges_size_type. So some clean-up seems to be needed. (Or is it the case, that nobody touches these original documentations anymore??) Thanks again. Oliver -- Dr. Oliver Kullmann Computer Science Department Swansea University Faraday Building, Singleton Park Swansea SA2 8PP, UK http://cs.swan.ac.uk/~csoliver/
The reason is that the iterator range defines the number of vertices.
I guess you mean the number of edges here.
Oops. You're right.
So, from what I can tell (assuming that I'm reading your intent correctly), the change that works will actually fix your problem.
This works now; thanks!
Shouldn't one then update the documentation? For the first constructor of adjacency_list (in the documentation), the parameters
edges_size_type m = 0, const GraphProperty& p = GraphProperty())
aren't explained, and at least m isn't used, and actually seems harmful?
I don't think it's wrong to not discuss the fact that m isn't used - well, maybe it is. I fixed the reference to vertices_size_type m = 0 in the docs on trunk so that it reads edges_size_type.
(Or is it the case, that nobody touches these original documentations anymore??)
If I have time, I plan on moving all of the documentation to quickbooks, with new examples and docs. Hopefully, I can get this done for 1.39. We'll see. Andrew Sutton andrew.n.sutton@gmail.com
If I have time, I plan on moving all of the documentation to quickbooks, with new examples and docs. Hopefully, I can get this done for 1.39. We'll see.
That's a good news. BGL is a lib I'm using and like very much! Will the BGL book be updated accordingly? Thanks for your contribution! B/Rgds Max
participants (3)
-
Andrew Sutton -
Max -
Oliver Kullmann