[boost] Re: Re: [BGL] forced client complexity

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-04-02 00:58:53

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