Hi Jeremy,
On Apr 1, 2004, at 1:49 AM, Vladimir Prus wrote:
Specifically, there reference is really lacking -- for example, try to figure out what the 'make_label_writer' function does
That is documented in write-graphviz.html. Did you find the explanation there hard to understand?
Sorry for being unclear. I mean that if I find 'make_label_writer' call in C++ code, I don't know where to look for documentation. There's no single list of all functions with links to documentation, ala "namespace members" in doxygen documentation.
(In general, I'm not particularly happy with the read/write graphviz interface, but I don't have time now to do a redesign)
and in what header it's defined.
I've added a "Where Defined" section.
Thanks.
I remember that I had similiar question about a bunch of other functions, too.
When you hit one, let me know.
Sure.
Another issue is that I never seem to remember how event visitors work and have to look it up in documentation, which invariably requires looking at 3 or 4 separate pages.
Any suggestions on how to improve this?
Not yet :-( Maybe I'll have some suggestion next time I'll use visitors.
My favourite problem is external property maps. I really think that I should be able to just run
topological_sort(G, back_inserter(order));
and don't bother if 'G' has vertex_index_t property or not. Currently, if I use anything else than vecS for vertex storage, the above code won't compile.
So is your problem with external property maps, or with some graphs that don't provide a vertex index property?
The problem is that if a graph don't privde vertex index property, then it's not possible to create efficient external property map -- the only way I know is std::map, which is not as fast as property maps which use indices.
Generally, most of the time I assume that all vertex descriptors are integers, and don't try to write really generic code, because I suspect it too much work.
I should admit that basic operations like iteration over adjacent vertices are fine -- they are a bit verbose, but it's not a big problem.
[snip]
To tell the truth, I have no idea how to specify vertex properties when adding vertex, so maybe this is the thing to improve first. We might have:
add_vertex(g, "brother");
This is how: add_vertex(std::string("brother"), g) or more explicitly: add_vertex(property<vertex_name_t,std::string>("brother"), g) which I have to admit is pretty ugly.
Ah, but the documentation does not say that std::string is convertible to property<vertex_name_t,std::string>("brother"), at least I can't find it. Also, what happens if vertex_propety is property<vertex_name_t, std::string, property<vertex_index_t, unsigned> > will conversion from std::string or property<vertex_name_t, std::string> work?
Perhaps one way to avoid the complication of using the property class would be to provide some support for the use of a plain struct where each member is a vertex property.
Probably, but we'd need to way to associate PropertyTag with each member. Another idea: isn't this a good application for named function parameters? add_vertex(g, vertex_name_t("brother").vertex_index_t(10)); ? I'm still in dark about named parameters used by BGL or the upcoming named param library, so is not sure if this exact syntax is implementable.
we can also have a way to find a vertex with specific value of specific property:
find(g, vertex_name, "brother")
Sure. Write it up and we'll add it :) It should only be a few lines of code.
Yea, but first the original poster should indicate if this is what he's looking for -- I never needed this myself. - Volodya