From: David Abrahams (abrahams_at_[hidden])
Date: 2000-09-19 23:26:53
From: "jeremy siek" <jsiek_at_[hidden]>
> Hmm, maybe PropertyMap is not as bad as I first thought.
...looks like progress...
> > > > Too much, I still think. Something short and sweet would be
> > you
> > > > must have "accessor" in the name, then how about
> > > > "edge_capacity::accessor(G)"?
> > > > [I still don't like accessor <growl>]
> Then this would be:
[see vector::size(), for example]
> And I suppose the type for the map would be:
> edge_property_map<Graph, edge_capacity>::type
> or just:
> edge_map<Graph, edge_capacity>::type
Mmm... Seems kind of arbitrary. Are we introducing a new concept, the
"edge_map"? I guess if you could get the metaprogramming right I'd rather
I think I can tell you how to make that work with MSVC if you need a hint.
> > > > > > edge_capacity::get(G, e)
> > > > > > edge_capacity::put(G, e, c)
> > >
> > > I can live with adding the above functionality to the adjacency_list
> > > class,
> > Is that really an adjacency_list function? I thought it was by
> > member of the property class (aka "plugin").
> The way in which internal properties are stored is entirely
> graph-class dependant, so the functionality really does "belong" to
> the graph class, regardless of how we define the interface. If we go
> with this interface, the edge_capacity::get() function would be a
> templated function that just dispatches to the graph-class's function,
> which probably counts as an argument against this interface. The
> following is a similar interface that wouldn't need the extra
> get(edge_capacity(), G, e);
That looks pretty good.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk