Re: [boost] interest in a "signal flow" library?

From: Stjepan Rajko (stipe_at_[hidden])
Date: 2007-02-27 13:16:45

> From: Braddock Gaskill <braddock_at_[hidden]>
> A few comments:
>
> 1) This "signal flow" library sounds very similar to the "pipes and
> filters" pattern.  If the name invokes that relationship, it might get
> more use (if it is up to the semantics of pipes and filters).

Thanks for the tip - I'll look into that.

> 2) Using functions or functors directly would avoid the need for any
> signal_link glue in many cases.  The output signal type could be
> derived from the return type of the function.

This would be clever - it limits the pipeline to signals of a single
type, but like you say there are many cases where this is sufficient.
I will try to add something that would allow the use of a
function/functor as a filter.

> I added the intermediate function object, because I know you can get
> the result type and signature from it...perhaps you can be clever and
> avoid it in most cases.  Or at least provide an in-line glue syntax like:

I'm already getting return types and args in the templates I wrote, so
I can try to swing what you suggest both with and without using
boost.function.

> This has the benefit that I need no signal_link glue objects, nor does
> my functional code require any knowledge of signals, slots, or
> signal_links.

This would indeed be great.

> 3) Rationale? Your example usage seems to be almost equivalent to:
>
> void imagePipeline() {
>   Image img = video_generator();
>   img = differencer(img);
>   img = flipper(img);
>   Vector vec = analysis(img);
>   database(vec);
>   display1(img);
> }
>
> Obviously this code is more readable by any C++ programmer and has no
> boost dependencies, and could even be called by a signal.  So exactly
> what is the rationale for signal_flow?
>
> The rationale could be the ability to dynamically reconfigure
> pipelines at runtime.  But your example doesn't seem to provide a way
> to do this (no "flow traversal" or visitor iteration).
>
> The rationale could be to dynamically build pipelines at runtime.  But
> your syntax is primarily for multiple stages at compile-time, and if
> you start building your pipeline one at a time you can just use
> signal.connect() calls.
>
> The rationale could be to provide parallelism to a data flow.  But
> boost::signals doesn't have (yet) the functionality to provide this.
>

My inspriation for writing this was dynamic building/reconfiguring of
pipelines at runtime, and the ease of syntax provided by the library.
Using boost.signals directly was a little too cluttered for me when
constructing large pipelines.  With your tip above (making a filter
out of a function by use of return type), the overall syntax becomes
even simpler.

After a little time using the library, the pipeline syntax became much
more readable and configurable for me than the C++ equivalent.
Although, that may be because I am also accustomed to graphical
component based programming environments (MAX/MSP, LabView, EyesWeb),
which make it really easy to connect things via a visual design.  Part
of my inspiration for signal_link was that I was curious if I could
replicate some of that in C++.

Thanks for a great discussion!

Stjepan