Boost logo

Boost :

From: jeremy siek (jsiek_at_[hidden])
Date: 2000-09-19 22:09:51

David Abrahams writes:
> Well, actually I think PropertyMap is a fine name for a concept, and much
> better than PropertyAccessor.
> It does say exactly what it means.

Hmm, maybe PropertyMap is not as bad as I first thought.

> > > Too much, I still think. Something short and sweet would be better. If
> 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:


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

> > > > > 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 definition a
> 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);

> > but I'd rather not add this interface to any graph concept.
> > That should discourage its use in a graph algorithm.
> Can we review the examples I've written about in light of whatever I've
> battered <wink> you into accepting? Would you mind writing the examples out
> so I can see how they look?

Sure, after your response to this one I'll write it up ;)



Boost list run by bdawes at, gregod at, cpdaniel at, john at