A Hippie Idea

[qtoptus]

Hello,

I was wondering if there is a technical issue if Qt adopts the Boost library Signals instead of the current mechanism where it requires a Qt-specific tool to perform a preprocessing stage which also requires a Qt-specific defined keywords.

Thanks.

[squidge]

It seems that Qt's signals are more flexible than Boost, however. Last time I used Boost, the signals were serialised and not thread safe. In Qt, you also have several options for each connection you make - eg, you can define a connection as 'direct' so it isn't queued, but another connection which uses the same signal at a different part of the program can be queued.

[qtoptus]

So Qt signals are thread safe?

Well the idea is just to liberate Qt from specific tools/keywords.

[SixDegrees]

So Qt signals are thread safe?

Well the idea is just to liberate Qt from specific tools/keywords.

...and shackle it to an external library that is underdeveloped, poorly specified and impossible to port to many compilers? What's the advantage?

[qtoptus]

I think boost is a pretty mature library and under active development.

Again the whole idea is to get rid of Q_OBJECT thingy and make it portable without being required(forced) to use Qt-Tools

Create Qt signal library that is "thread safe" and well developed!

[franz]

Qt is never ever going to use templates for stuff that can be auto-generated. If you wish, you can do without the Q_OBJECT macro. It's just a convenience macro. Not using it implies implementing the QMetaObject yourself, as well as some translation functions.

If you're wondering why this is, read their statement on using templates for signals and slots.

[SixDegrees]

Boost is a much more heavyweight solution than Qt, and it is far from portable; it simply will not compile in any useful form under many Unix compilers, and quality assurance is, at best, spotty. The latter will probably change once the standards committee actually releases a specification, but given their past performance that is at least a decade in the future.

[franz]

And besides that, the boost api is butt-ugly...

[qtoptus]

Understood.

[wysota]

To add to the discussion - Boost signals are "static" in the way that connections are established during compilation whereas in Qt they are established at runtime which gives many different opportunities Boost will never have. For example consider exposing an ActiveX or D-Bus interface on the fly or wrapping an external scripting environment (e.g. Javascript) in signal/slot/property system to connect two different technologies together. You can also "create" signals and slots dynamically for example as shown here: http://doc.qt.nokia.com/qq/qq16-dynamicqobject.html. Also an example of what I did was to allow remote registration for signals that were later passed between applications on different hosts using ActiveMQ bus. I can also imagine implementing dynamic IPC mechanism with signal/slots API although this is sort of what D-Bus already does (I would extend it to RPC though).