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
already...
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
is
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
to
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
the
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
to
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
with
our all favorite C++ compiler... However, 'put()' is fine for me.

Regards,
  Dietmar


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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