From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-04-01 01:49:46
Provisional Dissonance wrote:
> While I understand that the BGL is deeply entrenched
> in boost culture, certain academic circles, and even
> publications, I nonetheless suggest that BGL lacks the
> ease of use necessary for widespread adoption.
I think one of the biggest issue with BGL is documentation.
Specifically, there reference is really lacking -- for example, try to
figure out what the 'make_label_writer' function does and in what header
it's defined. I remember that I had similiar question about a bunch of
other functions, too.
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.
My favourite problem is external property maps. I really think that I should
be able to just run
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
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.
> digraph<some_node_type,some_edge_context_type> g;
> g << "vertex" << make_pair("vertex",
> g.add_edge("brother", "sister", "sibling");
> if(g.find(make_pair("brother", "sister")))
> related = true;
> Could someone please elucidate on why it is
> impossible/impractical/unnecessary/whatever for a
> graph library to have such an interface? Should I
> accept that the BGL is not the magic bullet graph
> library and move on, or can this kind of simplicity be
> somehow found within?
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:
we can also have a way to find a vertex with specific value of specific
find(g, vertex_name, "brother")
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk