Boost logo

Boost :

From: Dietmar Kuehl (dietmar_kuehl_at_[hidden])
Date: 2000-08-29 17:17:20

Greg Colvin wrote:

> From: <jsiek_at_[hidden]>
> > David Abrahams writes:
> > Of course, my preference is still not to use put() or set(), but
> > to use the operator[]. This looses the flexibility of a free function,
> > but it is very easy to read and automatically works for pointer types.
> Can we not have both set() and operator[]?
> > Renaming _p to _predecessor, and changing to operator[] gives
> > the following code:
> >
> > template <class Predecessor>
> > class predecessor_visitor
> > {
> > ...
> > typedef tree_edge_tag category;
> >
> > template <class Edge, class Graph>
> > void process(Edge e, Graph& g) {
> > _predecessor[target(e, g)] = source(e, g);
> > }
> > ...
> > };
> This reads much better to me.

I don't think we should require 'operator[]()'! I think we had this discussion
The problem is simply that many property accessors (or properties - I'm not fixed on

the name, only on the concept) do internal processing. An example is the computation

of the free capacity in a flow algorithm: Viewed in direction of the edge, the value
the total capacity minus the current flow, viewed in the opposite direction, it is
just the
current flow. Things like this are not too uncommon. Thus, I consider a requirement
have a method providing an lvalue to be changed a too strong requirement.

It may be possible to use a proxy which distinguishes between reading and setting
value. This would be OK but the proxy would have to be provided by the user of the
code. Well, it is probably possible to use a generic proxy... Still my perference is
separate reading and setting the value of a property into two different methods. The

natural names would be 'set()' and 'get()' but apparently 'set()' causes conflicts
our all favorite C++ compiler... However, 'put()' is fine for me.


Do You Yahoo!?
Get your free address at

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