On Jun 13, 2005, at 3:40 PM, martin f krafft wrote:

also sprach martin f krafft [2005.06.13.1249 +0200]:

...

I would like my nodes and edges to have behaviours. Bundled properties -- the method to attach struct instances to nodes and edges -- seems like the way to go. However, if that is the suggested method, then "bundled properties" is somewhat of a misnomer.

... and even if: how do you get the property object from am edge or vertex descriptor? If g is an adjacency list with Edge and Node structs as edge and vertex property bundles, and ei/vi are edge/vertex iterators respectively, then the following allows me to call Edge/Node::fn():

g[*ei].fn() g[*vi].fn()

This is rather awkward. Is there a better way?

Not really. If you can come up with a more natural syntax to express what you'd like to do, we can try to incorporate it into the BGL. Doug

On Jun 14, 2005, at 9:44 AM, martin f krafft wrote:

also sprach Doug Gregor [2005.06.14.1558 +0200]:

...

...

g[*ei].fn() g[*vi].fn()

This is rather awkward. Is there a better way?

Not really. If you can come up with a more natural syntax to express what you'd like to do, we can try to incorporate it into the BGL.

I'll think about it. One trivial way would be to store properties in the descriptors, rather than keeping a list of properties indexed by descriptor in the graph instance. Has this been considered?

Yes. When bundled properties were originally added, we talked about allowing property access through "->" on vertex and edge descriptors, because it would be convenient. Unfortunately it becomes a const-qualification nightmare. In the BGL now, descriptors just abstractly name a vertex or edge. To get to a property, you need to go through the graph (or, more commonly, a property map). If you have a const graph or property map, you get const property values; non-const graphs and property maps give non-const property values. If we put the properties in the descriptors, we need to have const and non-const descriptors, which then implies const and non-const versions of vertex_iterator, edge_iterator, out_edge_iterator, in_edge_iterator, and adjacency_iterator. The const_iterator/iterator difference in STL containers can get really annoying; this would be much worse. Doug

On Jun 14, 2005, at 1:35 PM, martin f krafft wrote:

also sprach Doug Gregor [2005.06.14.2006 +0200]:

...

property map). If you have a const graph or property map, you get const property values; non-const graphs and property maps give non-const property values. If we put the properties in the descriptors, we need to have const and non-const descriptors,

Your explanation makes perfect sense. One thing I am left to wonder though is why edge descriptors aren't const by definition. After all, I should not be allowed to modify them at all. Moreover, I should not be allowed to modify them if part of a const graph.

edge descriptors are meant to be "opaque"; the documentation doesn't say anything about their structure, so there are no guarantees about what they contain. In truth, everything in an edge description that doesn't involve copying or constructing should be private, but that couldn't be done when the BGL was written because most compilers couldn't handle templated friends. Doug