on Wed Sep 03 2008, "Stjepan Rajko" <stipe-AT-asu.edu> wrote:
On Wed, Sep 3, 2008 at 5:08 PM, David Abrahams <dave@boostpro.com> 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: http://archives.free.net.ph/message/20080706.145113.313c713e.en.html
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 http://www.boostpro.com