Jeffrey, you are right, changing the container from listS to vecS makes the problem disappear. I am not sure why the graphviz code was changed like that ( I forwarded my mail to Jeremy directly and may be he finds time to answer). Before I switched to listS I used to use vecS and there the descriptor is a normal integer (the index into the vector) so I think the dot file wouldn't look much different for a vecS - vertex_descriptor vs. vertexIndex. With listS vertex_descriptor is a hex address (that of the list element) like 0x83b3e78. When you print that into the dot file there is a problem because the dot facility cannot parse hex addresses (0x...) and so I had to filter the dot file to make 0x83b3e78 into something else, like HEX83b3e78. This may have prompted the change to begin with but unfortunately it doesn't work because it seems vertex_index doesn't exist for listS or I missing something that makes sure it does exist. Jean Jeffrey Holle wrote:

If I'd have to guess, I'd say that vertex_index is a vertex_descriptor when using VecS. I use write_graphviz with my graph employing VecS without a problem. I notice that your graph uses ListS. As a test, try switching to VecS, this would add clarity to the problem...

Jean Utke wrote:

...

Since I haven't gotten any reaction to this - after some more digging it seems the explanation lies with the changes made between revisions 1.17 and 1.21 of boost/graph/graphviz.hpp for instance for vertex printing: revision 1.17: line 254: out << *i; vs revision 1.21: line 263: out << get(vertex_index, *i);

I read the change comment from CVS: === Revision *1.18* /Tue Aug 12 01:15:37 2003 UTC/ (15 months, 3 weeks ago) by /jsiek/ : changed to print the vertex_index instead of the vertex_descriptor === I understand how vertex_descriptor works, I am not sure about vertex_index, I have not yet fully traced it back through the templates. Can somebody please explain this to me?

Thanks,

Jean

Jean Utke wrote:

...

I am running into a problem compiling code that uses write_graphviz which used to work e.g. for gcc 3.3 and boost versions prior to 1.31. As I am trying to move forward I am testing different gcc and boost versions. Here is the example code: ---------------------------------------------------------------- #include "boost/graph/adjacency_list.hpp" #include "boost/graph/graphviz.hpp"

class BoostVertexContentType { public: enum { num=100 }; typedef boost::vertex_property_tag kind; };

class BoostEdgeContentType { public: enum { num=101 }; typedef boost::edge_property_tag kind; };

int main(void) { boost::adjacency_list< boost::listS, boost::listS, boost::bidirectionalS, boost::property<BoostVertexContentType, int>, boost::property<BoostEdgeContentType, int> > b; std::ofstream anOutFileStream; anOutFileStream.open("test.dot",std::ios::out); boost::write_graphviz(anOutFileStream, b); anOutFileStream.close(); } ----------------------------------------------------------------- This compiles ok with gcc 3.3 and boost 1.30.0 / 1.30.2

It does not compile with gcc 3.3/3.4.3 and boost 1.31/1.32 basically complaining about:

boost_1_32_0/boost/graph/graphviz.hpp:269: error: no match for `std::basic_ostream<char, std::char_traits<char> >& << const boost::detail::error_property_not_found&' operator

My target right now is to use gcc 3.4.3 with boost 1.32. Before I spend time searching for a workaround I hope that somebody has seen this and that there is an easy solution.

Thanks,

Jean

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

-- Jean Utke Argonne National Lab./MCS utke@mcs.anl.gov phone: 630 252 4552 cell: 630 363 5753

Hi Doug, thanks for your reply. I do need to remove vertices/edges, hence the listS. There is the issue of dot not parsing hex addresses properly and I understand the reason for changing the code in this respect. I can add the additional property to all my graphs but that is overhead for me since I use the graphviz stuff for debugging only. Rather than incurring that overhead I would prefer to filter the hex addresses to dot-readable names and not print any labels. If people want to see their vertices indexed and printed like this they can add the vertex_index property and write their own label writers. Is there any chance for a graphviz code change that filters the hex addresses ? Jean

The GraphViz writer needs to be able to generate unique labels for each of the nodes. The easiest way to do that is to use the indices of the vertices. This is required because descriptors don't necessarily make good labels... it worked before for some graph types by accident.

To fix this, you would need to add a "vertex_index_t" property to the vertices in your graph and set them to values in [0, num_vertices(g)), usually like this:

vertex_iterator vi, vi_end; int i = 0; for(tie(vi, vi_end) = vertices(g); vi != vi_end; ++vi, ++i) put(vertex_index, g, *vi, i);

Actually, you'll probably find that using BGL algorithms becomes a lot easier after you've done this :)

The alternative suggested by Jeffrey Holle is easier, but only if you don't need to remove vertices from your graph.

Doug

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

-- Jean Utke Argonne National Lab./MCS utke@mcs.anl.gov phone: 630 252 4552 cell: 630 363 5753

Hi Jean, The vertex descriptor of a graph is not, *in general*, required to be something that one can print with an ostream. The vertex_index, however, is just an integer, which can be printed via ostream. However, to use this, your graph must have an internal vertex_index property. Does it have this? Cheers, Jeremy On Dec 3, 2004, at 12:05 PM, Jean Utke wrote:

Since I haven't gotten any reaction to this - after some more digging it seems the explanation lies with the changes made between revisions 1.17 and 1.21 of boost/graph/graphviz.hpp for instance for vertex printing: revision 1.17: line 254: out << *i; vs revision 1.21: line 263: out << get(vertex_index, *i);

I read the change comment from CVS: === Revision *1.18* /Tue Aug 12 01:15:37 2003 UTC/ (15 months, 3 weeks ago) by /jsiek/ : changed to print the vertex_index instead of the vertex_descriptor === I understand how vertex_descriptor works, I am not sure about vertex_index, I have not yet fully traced it back through the templates. Can somebody please explain this to me?

Thanks,

Jean

Jean Utke wrote:

...

I am running into a problem compiling code that uses write_graphviz which used to work e.g. for gcc 3.3 and boost versions prior to 1.31. As I am trying to move forward I am testing different gcc and boost versions. Here is the example code: ---------------------------------------------------------------- #include "boost/graph/adjacency_list.hpp" #include "boost/graph/graphviz.hpp"

class BoostVertexContentType { public: enum { num=100 }; typedef boost::vertex_property_tag kind; };

class BoostEdgeContentType { public: enum { num=101 }; typedef boost::edge_property_tag kind; };

int main(void) { boost::adjacency_list< boost::listS, boost::listS, boost::bidirectionalS, boost::property<BoostVertexContentType, int>, boost::property<BoostEdgeContentType, int> > b; std::ofstream anOutFileStream; anOutFileStream.open("test.dot",std::ios::out); boost::write_graphviz(anOutFileStream, b); anOutFileStream.close(); } ----------------------------------------------------------------- This compiles ok with gcc 3.3 and boost 1.30.0 / 1.30.2

It does not compile with gcc 3.3/3.4.3 and boost 1.31/1.32 basically complaining about:

boost_1_32_0/boost/graph/graphviz.hpp:269: error: no match for `std::basic_ostream<char, std::char_traits<char> >& << const boost::detail::error_property_not_found&' operator

My target right now is to use gcc 3.4.3 with boost 1.32. Before I spend time searching for a workaround I hope that somebody has seen this and that there is an easy solution.

Thanks,

Jean

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

-- Jean Utke Argonne National Lab./MCS utke@mcs.anl.gov phone: 630 252 4552 cell: 630 363 5753

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

_______________________________________________ Jeremy Siek <jsiek@osl.iu.edu> http://www.osl.iu.edu/~jsiek Ph.D. Candidate, Indiana University Bloomington C++ Booster (http://www.boost.org) _______________________________________________