Boost logo

Boost :

Subject: Re: [boost] Flow-based programming library for Boost?
From: Marcus Tomlinson (themarcustomlinson_at_[hidden])
Date: 2013-01-04 05:36:36

On 04 Jan 2013, at 11:46 AM, "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]> wrote:

> Le 04/01/13 08:51, Marcus Tomlinson a écrit :
>>>> * You use a bus of input/output untyped signals. Why the signals are not
>>>> typed?
>> 1. Flexibility - inputs and outputs can dynamically accept changing signal types. E.g. Varying sample size in an audio stream.
> I don't know why this couldn't be modeled with a vector signal containing the samples. Maybe you have other examples needing untyped iunterfaces.

Sorry, audio jargon. Sample size - the size of each sample. So changing a vector<char> to a vector<int> for example. The sample type needs to change hence the vector variable needs to change.

>> 2. Less coding, more expandability - the component designer need not specify the types required at each input / output when configuring IO, only how many. Consider the situation where you would like to update a component to accept int instead of bool for one of its inputs. This would (in your implementation) require you to edit multiple sections of code. With DSPatch, you need only edit / add to the process method.
> Well, my example is just a draft that can be polished. In particular the library could provide a macro that generates all this stuff from a free function.
> bool And(bool a, bool b) { return a && b);

This is better but still, the component is rather limited. It can only deal with 2 Boolean inputs and output a single Boolean. There is hardly room here to expand on IO count and types if needed in the future (perhaps at some point I'd like DspAnd to return "1" when x number of input integers are "1"). Again, I have to stress that these aspects of flexibility are very important to the purpose DSPatch serves. This makes me wonder though, perhaps I could use macros to simplify / enhance some aspects of DSPatch.

>> This looks like the kind of code you'd find in other dataflow libraries. However, this is exactly why I designed DSPatch, and why I designed it the way I did. In my opinion, the code is convoluted (doesn't read well). But alas, I fear that most people actually prefer this kind of syntax over mine.
> Syntax preference goes after covering all the needed functionalities. So I think that you will need to describe the needs you try to cover so that people like me don't request why you are doing things like you do ;-)

If you have a quick look over the feature list on the main page of the DSPatch documentation site ( you'll see what this library achieves by doing things the way it does.

> It would be great if the documentation describes this design rationale and show examples where this dynamic needs are evident and why it is impossible if not difficult to do it with a static model.

Ok, good point. I will add it to the list :)

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