On 09/07/2011 07:31 PM, Stephan Beal wrote:
On Wed, Sep 7, 2011 at 7:37 PM, Rui Maciel <rui.mac...@gmail.com
<mailto:rui.mac...@gmail.com>> wrote:
After rummaging through Qt's mailing list it appears that is a
known issue. Yet, I haven't found any reference on how to
circumvent these limitations. So, considering this, is there a
more up-to-date source of information regarding how to integrate
libsigc++ Qt code with Qt?
There's a description of a workaround here:
http://forum.urbiforge.org/viewtopic.php?f=6&t=4439
<http://forum.urbiforge.org/viewtopic.php?f=6&t=4439>
Thanks for the tip, Stephan. I'll paste the tip here to save it for
posterity.
<quote>
Hi,
you're right, there is a collision with 'emit'. However this is a huge
mistake from Qt, forbidding anyone to use the 'emit' identifier is
simply broken (it even collides with Boost signal). We won't rename
'emit' because it's the right name, and changing it would break backward
compatibility. We can work around the problem in our headers by
disabling the Qt macro locally, however you would'nt be able to call the
method yourself.
If you can, define QT_NO_KEYWORDS. This will prevent Qt from defining
its broken macros (emit, slots, ...). You can then use Q_EMIT instead to
emit signals, see the Qt documentation. This is how I usually proceed.
Otherwise, undefine Qt's emit before including our headers, and redefine
it (to nothing) after. Do so everytime you have to call an emit function.
Cheers,
</quote>
It can also be noted that it is also possible to employ sigc++'s functor
to emit signals.
If I'm not mistaken there is also another way where Qt screws with
libsigc++, which is solved by including libsigc++ headers prior to any
Qt header. Yet, I don't remember what problem this prevents.
Thanks for the help,
Rui Maciel
_______________________________________________
libsigc-list mailing list
libsigc-list@gnome.org
http://mail.gnome.org/mailman/listinfo/libsigc-list