
Boost : 
From: Stjepan Rajko (stipe_at_[hidden])
Date: 20080721 14:31:02
On Sun, Jul 20, 2008 at 9:37 PM, Brian Davis <bitminer_at_[hidden]> wrote:
> I looked through boost and if there is a library or facility for data
> binding in boost I could not find it... So I created and am submitting a
> simple example for review.
>
> [snip]
>
> Dataflow provides the event model data_binding
> provides the means to do data conversion between events.
Hi Brian,
You are right in that this combines two problems  one is binding
values together (the part that is very appropriate for Dataflow), and
the other is transformations of values (which is useful in itself).
Even though these could be left as orthogonal concepts, perhaps gluing
these two together might also be interesting.
I have tried to tackle the value/domain transformation problem a while
back, inspired by Brook Milligan's (CCd) probability library (which
can nicely transition probability values between linear and log
domains).
My attempt at a generic domaintransformation solution relied on a
"pivot" type. That is, you could transition from any domain to any
other domain as long as both specified how to transition to some
common, "pivot" type. This is where it is different from your
solution, where you specify pairwise transformations (I think in my
implementation you could also specify direct transforms, but I don't
remember).
E.g., here is how you implement a log domain:
http://pastebin.com/f6dd9c7d
... and some test code:
http://pastebin.com/f160d91e9
I think you can download the whole thing packaged with other stuff at:
http://ame4.hc.asu.edu/amelia/download/
Brook Milligan also worked on a generic domain transformation library,
so he might comment on this as well. There is also the Boost.Units
library which might offer transformations for some cases.
Going back to dataflow+transformations... If the two were left
separate, we could implement the binding (no transformations) part
easily as a part of the Dataflow library. That would mean you can
only bind together values of the same type/domain. I think it
basically reduces to a shared_ptr if you don't care about getting
notified about a change. On top of that, then, when you need bound
values to exist in different domains (e.g., Celsius, Farenheit,
sensor), each value can do it's own transformation to/from the shared
value (think star topology). This is similar to the "pivot" type
concept.
Now, there are times when this would not be desirable. One case is
when the transformations to the pivot type lose precision, so you'd
rather connect the bound values in a ring of some sort (or some other
connected component in graph terms), and each connection would have
transformations (one for each direction) built into it. Once a value
gets changed, the network would need to decide on which (one) path to
use to update each other value. Also, I think there are some
interesting lazy evaluation possibilities (don't calculate the
transforms until needed).
Anyway, I think it would be interesting to try to add some of this to
the dataflow library. Would you prefer the "star topology" solution,
or the other one (similar to yours) with arbitrary
connection/transformation topologies? (first can be seen as a special
case of the second, but maybe has a simpler implementation)?
Stjepan
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk