Boost logo

Boost :

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-09-19 17:35:08

----- Original Message -----
From: "jeremy siek" <jsiek_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, September 19, 2000 5:46 PM
Subject: Re: [boost] Graph stuff

> David Abrahams writes:
> > I don't see the problem here. You _are_ accessing the property... of
> > entire graph! Then you can index the property with the particular edge
> > vertex descriptor (you didn't throw out operator[] for
> > did you?) It makes complete sense to me (of course ;)), and I think
> > once you've been exposed to the structure
> > the first time there are fewer constructs to remember.
> I'd still feel better if we could work the word 'accessor' into the
> interface.

Look, it's really not an accessor the way you've defined it... it's more of
a reference. In some sense, it's just like a descriptor - an abstract
identifier for the value(s) in question. The accessing all happens inside of

But anyway, I am fighting you because I don't want users to have to be
burdened with the (long) word "accessor". I know it means something to you,
but if we force users to come to grips with the concept, it's just more
mental overhead. I don't think there is commensurate benefit to having a
separate concept. I'm just trying to make this very powerful library easy to
learn and use.

> > That's why I suggested using edge_property<Graph, edge_capacity>::type
> > I still prefer edge_capacity::get(G) to get the edge_capacity of the
> > graph.
> How about replacing '::type' with '::accessor': we go again... ;-)
For the same reasons mentioned above. Okay, I can understand why
edge_property<Graph, edge_capacity>::type might sound like the value_type of
the edge property. Maybe accessor is okay here, but I'd rather avoid it.
Even "descriptor" would be better. These really are the same concept, aren't

> edge_property<Graph, edge_capacity>::accessor
> And for the function, could you live with 'get_accessor'
> edge_capacity::get_accessor(G)

Too much, I still think. Something short and sweet would be better. If you
must have "accessor" in the name, then how about
[I still don't like accessor <growl>]

> > edge_capacity::get(G, e)
> > edge_capacity::put(G, e, c)
> >
> > The more tokens you make people type/read the less usable your library
> > and the less maintainable your users' code is.
> The problem with what you've written above is that it is less generic.
> It is nice to be able to use both "interior" and "exterior" property
> accessors with a graph algorithm (the interface above only works for
> "interior" accessors). For example, you need vertex color to do
> breadth_first_search(), but you may not want to keep color around for
> the entire lifetime of the graph, a waste of space. So you allocate a
> vector, use it as a property accessor in BFS, then deallocate.

Fine, I have no problem with keeping the generic interface. And one should
use the generic interface for generic algorithms. But what about the poor
user who has built a specific graph and just wants to extract the least-cost
predecessor values from his vertices after running Djikstra?


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