Re: [boost] [BGL] MutablePropertyGraph questions

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-01-29 11:31:57

Jeremy,

> On Wed, 29 Jan 2003, Vladimir Prus wrote:
> ghost>
> ghost> Oh.. I only now realized how to use ReabablePropertyGraph concept:
> ghost>
> ghost>    function_requires< ReadablePropertyGraphConcept<G, edge, edge_weight_t> >();
> ghost>
> ghost> Are you suggesting that this become
> ghost>
> ghost>    function_requires< EdgePropertyGraphConcept<G, edge_weight_t> >();
> ghost>
> ghost> and the same split done to PropertyGraphConcept and LvaluePropertyGraphConcept?
> 
> I'm not so sure that change is worth it because the Edge/Vertex versions
> would look exactly the same except for name unless I am mistaken.

1. I think one of them will look for a property in edge_property<G> and
    another in vertex_property<G>

2. Why do you think that MutablePropertyGraph *should* be split?

> ghost> I agree. The type basically is a structure, which fields are not named in a
> ghost> regular C++ way, but are identified by type. A subscript operator can take the
> ghost> "tag" type and return the value (or reference to it). Lookings at the code,
> ghost> it seems like this is actually implemented.
> ghost> BTW the following code does not compile for me at the moment. Is it correct?
> ghost>
> ghost>      typedef adjacency_list<vecS, vecS, property<vertex_name_t, int,
> ghost> 				    property<vertex_distance_t, int> > > G;
> ghost>
> ghost>      vertex_property<G>::type p;
> ghost>      // p[vertex_edge_t()] = 10;
> 
> No, operator[] is not supported for the property class, though it is
> supported for property maps (I know, the naming here is a bit confusing).

1. In fact, it fails to compile with the last line *commented*. There's 
something wrong with the second one.

2. The question is whether operator[] should be supported. So far, the only
    way edge_property<G>::type can be used is by passing it to new_edge
    function -- i.e. to duplicate properties of an existing edge.

> ghost> I think the best approach would be to make this concept explicit, and
> ghost> independent from BGL. Something like
> ghost>
> ghost>    type_indexed_container<
> ghost>      mpl::list<
> ghost> 	pair<vertex_name_t, int >,
> ghost> 	pair<vertex_distance_t, int> > > c;
> ghost>    c[vertex_name_t()] = 10;
> ghost> 	I wonder if something like this already exists... I vaguely recall
> ghost> someone was doing that.
> 
> Yes, Emily Winch was working on this, and I thought she was going to
> submit to boost. The following URL has a paper she wrote about this.
> 
> http://www.oonumerics.org/tmpw01/schedule.html

Thanks for the link. That's what I meant, indeed. Do you think that such 
container can be used in BGL properties implementation, when available?

BTW, I think I like mpl::list-based syntax better than chaining of types...

- Volodya