Boost logo

Boost :

Subject: Re: [boost] [gsoc] Interest in BGL v2?
From: Andrew Sutton (asutton.list_at_[hidden])
Date: 2011-03-31 18:23:17


> It sounds to me like you are going to end up keeping the BGLv1 functional graph concepts for compatibility, and also providing STL-style OO concepts (I prefer this aesthetic too).  I'll strive to be compatible with both, if possible.

There are going to be some direct analogs, but they won't be the
"same". Different names, (hopefully) clarified semantics, etc. For
example, vertex_descriptor and edge_descriptor simply become vertex
and edge and are required to be convertible to bool (so you can test
to see if they're valid or not). The edge function is replaced by
get_edge, with adjacency matrices (eventually) supporting m(u, v).
AdjacencyGraph is probably going to go away since adjacency is just an
abstraction over incidence.

Oh... we don't support "edgeless" graphs, but the BGL doesn't really
do that either.

> I don't see how the old graph concepts are confining in any way, if anything they are sometimes too loose, e.g. when a node object is self-sufficient and you don't need the graph to lookup its edges.  Not that I'm complaining; I understand why they are this way.

They're confining in the sense that trying to model them would
actually constrain the design to matching those semantics. We don't
want to follow suit. We want to reevaluate and redesign.

On a side note, we actually went through a design iteration where we
considered making nodes (and edges) self-sufficient. It ends up
requiring avoidable overhead for vertex and edge objects in the
general case. We didn't want to mandate the additional memory costs,
so we're stuck with the same kinds of interface. You need the graph
for all of your interesting calls.

You can wrap a vertex (or edge)/graph pair to create reliably
self-sufficient abstractions. We haven't really explored this design
avenue, though.

> +1 on all this - I'll be watching with rapt attention, and following your lead.

Maybe we'll have a user in the future? :)

Andrew


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk