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

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

> From: Michael Marcin <mike_at_[hidden]>
>
> These operator overloads for connecting multiple signals seem too cutesy
> and confusing.  How often do these long chains of signals get connected
> together?  I would imagine at most a dozen such chains for a complex
> application but maybe I'm wrong.  Braddock brings up good points and I
> find his imagePipeline function much easier to read (it will also almost
> certainly be easier to debug and to mentally assure myself of correctness).

In the applications I'm currently working with there really aren't
that many chains/pipelines and they really aren't that big (several to
about a dozen).  The whole signal mechanism involves a little hit on
efficiency, so it probably shouldn't be used to connect the smallest
components of the code.

I found the greatest benefit of this mechanism after getting used to
the syntax and developing a few components that used it.  It became
really easy to prototype applications and whip up new things from
existing components in no time.  The whole mentality of using signals
and slots encourages development of components that are more concerned
about the data than where they are getting the data from (and although
good C++ practices should probably focus on the same I know that's not
always the case at least for me).  When you combine this with the
ability to easily interconnect components (through simple syntax), it
gives nice benefits.

I definitelly agree with you regarding debugging - debugging with
signals can be a bit of a pain :-)

Stjepan