On Tue, Jun 16, 2015 at 12:04 AM, Vladimir Prus
On 6/16/2015 3:52 AM, Emil Dotchevski wrote:
I've made changes to Boost Synapse (a signal programming library) in part based on feedback I received on the Boost mailing list, and I've uploaded the updated source code and documentation to github: http://zajo.github.io/boost-synapse/.
Emil,
I've glanced through the tutorial and examples. The way you make signals 'external' to the class is quite smart.
However, I have two questions:
- There does not appear a way, given QObject*, to determine which signals are attached to it. Such reflection is one of the primary reasons MOC still exists, so your library will not eliminate the need for MOC?
I'm not an expert on Qt and there might be more reasons to need MOCing, but I know for a fact that it is needed in order to add new signals to an existing type. If you want to have a QDialog that emits your own custom signals you must derive from QDialog, add the signals and MOC. Using Synapse this can be avoided.
- Looking at the first example, I can't help wondering why I would want to use the library - given that I can use QObject::connect, either classic or with function object, why would I use an extra library?
It really depends - if you're willing to couple any amount of your own code with Qt, then you (obviously?) don't need Synapse. To me it is useful for similar reasons that boost::function is useful: it lets me pull things apart and decouple them. In the few Qt programs I've written, I'm using Synapse as glue between the user interface code and the rest of the program, while the UI code itself (being already coupled with Qt) mostly doesn't use Synapse internally (except to add custom signals since I don't use MOC.) Anyway, Synapse wasn't motivated by Qt, but by having to hook up callbacks from other APIs that weren't quite as good as Qt, only it turned out it's more practical than that. For example, one problem that has been quite annoying for me in the past is how to connect a boost::function to a Windows message. Synapse makes this a no-brainer. I guess this is really what defines the library: it lets you connect a boost::function to, dare I say, anything? :) Thanks, Emil