Boost logo

Boost :

From: Stjepan Rajko (stipe_at_[hidden])
Date: 2007-02-24 12:54:43


> From: <james.jones_at_[hidden]>
> Not an altogether different scheme, but why does:
>
> path11 (op) path12
>
> have to evaluate to path11? Why can't it evaluate to a proxy object which refers to path11? As long as it does this, you don't need to worry about order of evaluation.
>
> (path11 (op) path12) (op) path13 evaluates to
> proxy(path11) (op) path13 evaluates to
> proxy(path11)
>

Hmm... maybe I'm missing something. Here's where I'm having a problem:
Say you have:

source
 op1 (path11 op2 path12 op2 path13)
 op1 path2

The intended outcoume is:
 path11 connected to path12
 path12 connected to path13
 source connected to path11
 source connected to path2

Assume both op1 and op2 are left-to-right evaluated operators. The
order of expressions evaluated is:
 1. path11 op2 path12
 2. (result of 1.) op2 path13
 3. source op1 (result of 2.)
 4. (result of 3.) op1 path2

In order for 2. to do what it needs to do (connect path12 to path13),
result of 1. must include something that refers to path12(reference,
proxy,...). However, in order for 3. to do what it needs to do
(connect source to path11), result of 2. must include something that
refers to path11, which means that the result of 1. also needed to
include something that refers to path11. Hence, the operators would
need to return a struct (for example), that refers to multiple objects
(say, the leftmost and rightmost in the so far connected chain).
Perhaps this is what you meant by your use of proxy?

While this might be doable and result in the same intuitive and
readable way of connecting signal networks, using two operators that
do the same thing (connect left object to right object, return
reference to left object), but one operator is left to right (intended
for branching) and the other is right to left (intended for chains),
seems simpler (at the cost of making use of an unconventional operator
like >>=).

What do you think?

Stjepan


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