Re: [boost] [review] Dataflow Library

Subject: Re: [boost] [review] Dataflow Library
From: Stjepan Rajko (stipe_at_[hidden])
Date: 2008-09-03 23:34:20

On Wed, Sep 3, 2008 at 5:08 PM, David Abrahams <dave_at_[hidden]> wrote:
>
> I was reading other review commentary when it occurred to me that
> Boost.Accumulators is also implementing a dataflow system.  I would like
> to know if Stjepan considered Boost.Accumulators and whether his library
> could build on some of that work.
>

I have looked at Boost.Accumulators, and really like it's dataflow
characteristics, especially the way it deals with dependencies.  As
far as building on it, at the moment the Dataflow library is in it's
entirety focused on connecting components at run-time, and (unless I
am mistaken), the dataflow connections in a Boost.Accumulators
accumulator_set are all determined at compile time.  So far, my only
adventure into compile-time connections was a brief component
composition study for Dataflow.Signals, where I verified that one
could take a chain of components (what would at run-time be connected
using the syntax, e.g.,  c1 >>= c2 >>= c3) and turn it into a single
component that performs the same operation, but with the intermediate
calls being connected at compile-time.  By that I mean that, e.g.,
where in the run-time chain c1 would send a signal using Boost.Signals
to c2, in the compile-time composition c1 calls c2 directly (with the
call possibly being optimized out by the compiler).

At some point (and that might be far into the future), I would like to
extend the Dataflow library to the compile-time realm.  At that point,
it will need a way for dataflow networks to be specified at compile
time, and so far my thoughts on possible ways of doing that are:
 * using Proto expression trees
 * using, factoring out, or mimicking the way Boost.Accumulators does it
 * using a compile-time metagraph library, like the one suggested by
Gordon Woodhull:
http://archives.free.net.ph/message/20080706.145113.313c713e.en.html

Best,

Stjepan