From: Braddock Gaskill <braddock@braddock.com> 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