Boost logo

Boost :

From: jsiek_at_[hidden]
Date: 1999-12-08 23:01:31

Ok, I'll send up the white flag on this one :)

Dietmar Kuehl writes:
> Hi,
> At 12:02 PM 12/8/99 -0500, jsiek_at_[hidden] wrote:
> >So the main reason Dietmar does not like operator[] is that you need a
> >proxy class to implement the various semantic flavors that are needed.
> The proxy is one reason why I'm opposed to the 'operator[]()'. There
> is another reason: 'operator[]()' needs to be a member function, it
> cannot be a global function. Thus, it is impossible to add a version
> taking a different kind of descriptor, eg. a wrapper around the original
> descriptor, as argument. Why would somebody want to wrap a
> descriptor? For example to cope with a temporarily modified graph
> which somehow deals with the additional nodes (a simple example: a
> network with added super source and super sink). The added function
> could inspect the descriptor and depending on its value delegate the
> request to the original property accessor or to some other accessor.

Yes, this is a similar reason to why I did not want the adj() etc.
functions to be member functions of the graph object. global functions
are almost always better and more generic. If only operator[] could be
a global function!

> The use of read/write accessors is quite common: Basically all flags
> and temporary values use read/write accessors. However, even the
> simplest of these uses, eg. Boolean flags, are rather likely to use
> accessors which do not provide access to an lvalue. For example,
> to avoid going through the whole graph to clear a flag in multiple
> calls to an auxiliary algorithm (eg. a path search in the augmenting
> flow algorithm) a simple technique using an integer can be used:

Ahh, yes we do this in GGCL too. It would be easier without proxying.



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