Boost logo

Boost :

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
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:
>
> edge_capacity::get_map(G)

or simply:
   edge_capacity::map(G)

[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
see:

   property_map<Graph, edge_capacity>::type

or

   edge_capacity::traits<Graph>::type

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
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
> indirection:
>
> get(edge_capacity(), G, e);

That looks pretty good.

-Dave


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk