Quote Originally Posted by squidge View Post
You make some excellent reasonings in your article in which I am very interested. It would be awesome to be able to connect signals to standard function pointers rather than defined slots so I can put them wherever, without having to worry about defining them in header files with Q_SLOT or suchlike and ensuring I run 'moc' on the file. I always thought it was strange having both the signal and slot name and parameters in ascii text strings (which is basically what SLOT and SIGNAL macros do, for anyone getting confused) and doing so does give away information on how your application is structured and works (which sometimes you may not wish to give someone).
Saying this you end up closer to the concept of callbacks which is exactly what Qt signal/slot mechanism wants to avoid. I too like the idea of using lambdas as slots although this is hardly object oriented and lambdas are not part of the C++ standard yet anyway.

I don't see how you can compare the signal signature to the slot signature (type checking) in the compile stage yet however.
In a general case you can't simply because some signals and some slots do not exist at a time of compilation, for example when connecting DBUS or COM (ActiveX) components.

Commenting on nroberts' idea that signals and slots should be an addon to Qt (if I understood correctly) this wouldn't make much sense as signals and slots are the core of Qt and are used practically everywhere by Qt itself. There has been a discussion whether statically connected signals/slots would be better (sorry, no single link to give for reading) and the conclusion is that it is true that static connections (and invokations) are faster (about twice as fast as Qt's signals) but provided that you want to do anything practical in the slot, the "overhead" will be neglectible compared to the contents of the slot. Statically compiled signals also reduce functionality of signals and slots - you can then forget about dynamic introspection (for example across library boundaries).

And concluding - if you want static signal/slot mechanism, there is one provided by boost. Qt doesn't prevent you from using boost signals in any way. On the other hand dynamic signals (such as the ones in Qt) are much much more flexible, imagine building (on the fly) a meta-object for a remote webservice based on introspected description it provides (like wsdl or something similar) and connecting that directly to signals and slots in your application. It's something that static signals will never be able to do.