From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-04-02 00:58:53
> 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
> 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.
>> I remember that I had similiar question about a bunch of
>> other functions, too.
> When you hit one, let me know.
>> Another issue is that I never seem to remember how event visitors work
>> 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
>> 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
> 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
>> are fine -- they are a bit verbose, but it's not a big problem.
>> 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
>> 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_index_t, unsigned> >
will conversion from std::string or property<vertex_name_t, std::string>
> 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
> 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?
? 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
>> find(g, vertex_name, "brother")
> Sure. Write it up and we'll add it :) It should only be a few lines of
Yea, but first the original poster should indicate if this is what he's
looking for -- I never needed this myself.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk