Boost logo

Boost :

Subject: Re: [boost] [review] Dataflow Library
From: David Abrahams (dave_at_[hidden])
Date: 2008-09-04 09:51:42

on Wed Sep 03 2008, "Stjepan Rajko" <> wrote:

> 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.

I believe that is correct, except for "dropping" of accumulators, which
adds a runtime component.

I am not really an expert on what you'd use such a library for It seems
like compile-time configurability is of much greater interest in general
for problems you'd approach with dataflow, especially if you are using a
DSEL to describe the system. In other words, when you actually *need*
runtime configurability you'd probably want a graphical front-end or
something, and the syntax of making connections in C++ wouldn't matter
much. Am I missign something?

> 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:

Yeah, I couldn't really get a grip on what Gordon was describing, so I
thought I'd wait for his "soon, soon" which AFAIK hasn't happened yet

Dave Abrahams
BoostPro Computing

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