Re: [boost] [BGL] forced client complexity
Hi, I too am dissatisfied with the complexity of many parts of the BGL... On Mar 31, 2004, at 4:48 AM, Provisional Dissonance wrote:
Is there any particular reason that a simplified interface is not made available?
Just a lack of time. The priority was placed on providing flexibility and efficiency so that the BGL components could handle any situation... that flexibility came at the price of complexity. I think a good next step would be to provide more special purpose components that are easier to use.
Perhaps a container adapter could be packaged with the library allowing a compromise of functionality and flexibility for simplicity?
Could you explain this "container adaptor" idea more.
#include
... digraph g; g << "vertex" << make_pair("vertex", "implicit_vertex"); g.add_edge("brother", "sister", "sibling"); if(g.find(make_pair("brother", "sister"))) related = true;
Perhaps this is a good place to start. Could you
explain each of the above lines of code. Then
we can compare to an implementation in the current BGL
and pinpoint problem areas.
Cheers,
Jeremy
_______________________________________________
Jeremy Siek
On Wed, 31 Mar 2004, Jeremy Siek wrote:
#include
... digraph g; g << "vertex" << make_pair("vertex", "implicit_vertex"); g.add_edge("brother", "sister", "sibling"); if(g.find(make_pair("brother", "sister"))) related = true; Perhaps this is a good place to start. Could you explain each of the above lines of code. Then we can compare to an implementation in the current BGL and pinpoint problem areas.
The only thing I've ever found complex in the BGL is actually forming a graph type out of adjacency_list. Every single time I need a graph I have to read through the adjacency_list documentation to figure out what to do, although often I just copy the typedef from somewhere else. Simplified graph adaptors could really help here. There's a lot we could do in the way of syntactic sugar. For instance, I'd love to be able to easily loop over the edges in a graph without dealing with iterators directly: Graph g; for(Graph::vertex_descriptor u, v; (u, v) = G; ) { // do something with edge (u, v) } The same thing can be applied to, e.g., adjacent vertices: for(Graph::vertex_descriptor v; v = adj(u, g); ) { // v is adjacent to u } Since vertex descriptors tend to be iterators or indices, this could be implemented just as efficiently as the corresponding iterator loop, but it's a simpler idiom. Doug
Hi Doug, On Mar 31, 2004, at 1:52 PM, Douglas Paul Gregor wrote:
The only thing I've ever found complex in the BGL is actually forming a graph type out of adjacency_list. Every single time I need a graph I have to read through the adjacency_list documentation to figure out what to do, although often I just copy the typedef from somewhere else. Simplified graph adaptors could really help here.
Right. In particular, the way internal properties are dealt with is rather cumbersome.
There's a lot we could do in the way of syntactic sugar. For instance, I'd love to be able to easily loop over the edges in a graph without dealing with iterators directly:
Graph g; for(Graph::vertex_descriptor u, v; (u, v) = G; ) { // do something with edge (u, v) }
The same thing can be applied to, e.g., adjacent vertices:
for(Graph::vertex_descriptor v; v = adj(u, g); ) { // v is adjacent to u }
Since vertex descriptors tend to be iterators or indices, this could be implemented just as efficiently as the corresponding iterator loop, but it's a simpler idiom.
Looks neat. How would that be implemented? I hope it doesn't require
storing something in the graph object itself that keeps track of
the progress of the iteration.
BTW, for those who like macros, there's
boost/graph/iteration_macros.hpp.
Cheers,
Jeremy
_______________________________________________
Jeremy Siek
Jeremy, On Wed, 31 Mar 2004, Jeremy Siek wrote:
On Mar 31, 2004, at 1:52 PM, Douglas Paul Gregor wrote:
The only thing I've ever found complex in the BGL is actually forming a graph type out of adjacency_list. Every single time I need a graph I have to read through the adjacency_list documentation to figure out what to do, although often I just copy the typedef from somewhere else. Simplified graph adaptors could really help here.
Right. In particular, the way internal properties are dealt with is rather cumbersome.
Actually, I'm guessing that was part of the suggested "digraph" adaptor:
that vertices implicitly have names of a particular type and that a name
can be directly mapped to a vertex by the adaptor. About 3/4 of the time I
have a BGL graph (and I have a LOT of BGL graphs <g>) I also have a
map
Looks neat. How would that be implemented? I hope it doesn't require storing something in the graph object itself that keeps track of the progress of the iteration.
Uh-oh. I had an implementation in mind, but now I see that it was flawed. I'll just go sit in the corner now.
BTW, for those who like macros, there's boost/graph/iteration_macros.hpp.
Ah, the BGL is full of wonders! Doug
Douglas Paul Gregor wrote:
The only thing I've ever found complex in the BGL is actually forming a graph type out of adjacency_list. Every single time I need a graph I have to read through the adjacency_list documentation to figure out what to do, although often I just copy the typedef from somewhere else. Simplified graph adaptors could really help here.
Agreed. For example, I never can remember the order of all template
arguments to adjacency_list, and declaration of properties. Maybe, some
combination of "named template parameters" and mpl::list would help:
adjacency_list< graph_config<
vertex_property_t, mpl::list
On Apr 1, 2004, at 1:17 AM, Vladimir Prus wrote:
The "associative_list" that was posted some time ago probably can be used to implement this syntax.
Anyone volunteering to move the associative_list forward into boost?
(BTW, shouldn't we move this conversation to the main mailing list. After all, we're not talking how to use existing interface, but how it can be improved).
I'm still interested in hearing more feedback from users about problem
areas
in the current interface.
Cheers,
Jeremy
_______________________________________________
Jeremy Siek
Jeremy Siek wrote:
The "associative_list" that was posted some time ago probably can be used to implement this syntax.
Anyone volunteering to move the associative_list forward into boost?
Good question, but isn't it more the the author of associative_list? Anyway, I think it's fine to try using that class in some parts of BGL even if it's not officially accepted. We can hide it in "detail" directory ;-) - Volodya
participants (3)
-
Douglas Paul Gregor
-
Jeremy Siek
-
Vladimir Prus