Boost logo

Boost :

Subject: Re: [boost] Flow-based programming library for Boost?
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2012-12-08 22:02:16

Marcus Tomlinson wrote:

> Is there any interest out there for a library that allows you to create
> fast, efficient flow-based programs with an easy-to-use object-oriented
> interface? (
> I've created an open-source library that does this, called "DSPatch" (
> and would like to contribute it to
> the Boost Libraries.

I'm certainly interested in a Boost library that offers efficient
flow-based multithreading with an interface that is as simple as
possible. In fact I have some ideas of my own which I would gladly
present to the mailing list when I find more time.

As has been pointed out by other people, there are lots of dataflow
libraries out there, all offering similar functionality. I believe the
reason for this is that it's hard to get right. In particular, it's
hard to offer the functionality through an interface that is truly
simple enough.

I think your proposal suffers from this same problem. As far as I'm
concerned users should not need to inherit from a class in order to do
flow-based programming, nor should they need to create a circuit
object to provide wiring between the working components -- let alone
have to invoke methods on said object for each worker /and/ for each
connection. The connection methods have four arguments, which is too

On top of that I think a dataflow programming library can and should
be more powerful. Your framework allows for many-to-many connections,
but as far as I can tell from your documentation there are no standard
facilities that handle generic patterns such as distributing worker
output over multiple receivers. There doesn't seem to be a way to
directly extract multiple values in succession from an input
DspSignal(Bus). Polymorphism on the connections is handled by dynamic
typing while it could be static. I suspect there are more limitations.

Finally I believe object oriented design offers no advantage for
dataflow programming. It's not really in line with common Boost style

Concluding, while I fullheartedly agree with your intentions, I would
vote against your library if you were to submit it for a formal
review. I'm sorry to say this but I think Boost needs something that
is both simpler and more flexible.


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