Port QT call to BOOST - Resolved
Was quite easy actually. :-)
#include <iostream>
#include
j.c. wrote:
Was quite easy actually. :-)
It should be noted that in general, porting Qt signals/slots to Boost is not possible: 1. Qt signals/slots are dynamic, so declaration of either signal or slot need not be present in the static type of objects being connected. 2. Boost does not support inter-thread signals. (I'm not making any statement which model is best, just pointing out the differences) - Volodya
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 01 January 2008 17:13 pm, Vladimir Prus wrote:
It should be noted that in general, porting Qt signals/slots to Boost is not possible:
1. Qt signals/slots are dynamic, so declaration of either signal or slot need not be present in the static type of objects being connected.
Could you elaborate on what you mean by dynamic? I haven't used qt signals/slots since qt 3, but in those days I believe both the signal and slot end had to be in classes derived from QObject, plus have the Q_OBJECT macro in their declaration, as well as "slots:" and "signals:" pseudo-access specifications for the moc preprocessor to chew on.
2. Boost does not support inter-thread signals.
thread_safe_signals in the review queue does, although it doesn't have a review manager yet.
(I'm not making any statement which model is best, just pointing out the differences)
- -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHe7nG5vihyNWuA4URAk+5AKCuSaDgrGBtde8jhQgqRwqIx8x4wACg5R3W T/C7m/pGSyFeJraI89WKbEI= =wdYp -----END PGP SIGNATURE-----
Frank Mori Hess wrote:
2. Boost does not support inter-thread signals.
thread_safe_signals in the review queue does, although it doesn't have a review manager yet.
I meant to ask: does the thread_safe_signals submission include a summary of API differences from the 1.34 signals library? I remember there was substantial e-mail discussion about that, but I can't remember the outcome.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 02 January 2008 14:27 pm, Nat Goodspeed wrote:
I meant to ask: does the thread_safe_signals submission include a summary of API differences from the 1.34 signals library? I remember there was substantial e-mail discussion about that, but I can't remember the outcome.
Hmm, no. It does seem like it should have one though, I'll add a section to the documentation for that. - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHe/G85vihyNWuA4URAoGbAKCA283D0pf4ths50s2EMdqvglHsawCbBKgo aQZZTgO2A37+DNr/jQaZ9/8= =mYp8 -----END PGP SIGNATURE-----
Frank Mori Hess wrote:
On Wednesday 02 January 2008 14:27 pm, Nat Goodspeed wrote:
I meant to ask: does the thread_safe_signals submission include a summary of API differences from the 1.34 signals library? I remember there was substantial e-mail discussion about that, but I can't remember the outcome.
Hmm, no. It does seem like it should have one though, I'll add a section to the documentation for that.
Thanks! Some of my colleagues are eager to switch to thread_safe_signals. If there are ways we should constrain our current use of the signals library to make that future conversion easier, I'd like to know them.
On Wednesday 02 January 2008 17:55 pm, Nat Goodspeed wrote:
Thanks! Some of my colleagues are eager to switch to thread_safe_signals. If there are ways we should constrain our current use of the signals library to make that future conversion easier, I'd like to know them.
I've added an entry to the FAQ summarizing the changes from Boost.Signals 1.34, see: http://www.comedi.org/projects/thread_safe_signals/libs/thread_safe_signals/... -- Frank
Frank Mori Hess wrote:
I've added an entry to the FAQ summarizing the changes from Boost.Signals 1.34, see:
http://www.comedi.org/projects/thread_safe_signals/libs/thread_safe_signals/...
Thank you! The fact that slot is now callable as a function object may be the lever with which I can nudge everyone over to using this new library. :-) Depending on the timing of the review, by then I hope to have played with thread_safe_signals enough to give you tangible feedback. :-)
Frank Mori Hess wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday 01 January 2008 17:13 pm, Vladimir Prus wrote:
It should be noted that in general, porting Qt signals/slots to Boost is not possible:
1. Qt signals/slots are dynamic, so declaration of either signal or slot need not be present in the static type of objects being connected.
Could you elaborate on what you mean by dynamic? I haven't used qt signals/slots since qt 3, but in those days I believe both the signal and slot end had to be in classes derived from QObject,
Right.
plus have the Q_OBJECT macro in their declaration,
Right.
as well as "slots:" and "signals:" pseudo-access specifications for the moc preprocessor to chew on.
Not exactly. In order to 'connect' call to compile, you don't need anything extra at all -- either slot or signal being connected is allowed to not exist in the dynamic type of the objects, or not exist in the static type. At runtime, connect will check if the signal and slot are actually present, and connect them if so.
2. Boost does not support inter-thread signals.
thread_safe_signals in the review queue does, although it doesn't have a review manager yet.
I think it's not that. "inter-thread" signals are signals that are send from one thread, and delivered and processed in another thread. I don't think such solution for boost was announced in any form on mailing lists. See http://doc.trolltech.com/4.3/threads.html#signals-and-slots-across-threads for more details. - Volodya - Volodya
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 02 January 2008 14:43 pm, Vladimir Prus wrote:
as well as "slots:" and "signals:" pseudo-access specifications for the moc preprocessor to chew on.
Not exactly. In order to 'connect' call to compile, you don't need anything extra at all -- either slot or signal being connected is allowed to not exist in the dynamic type of the objects, or not exist in the static type.
At runtime, connect will check if the signal and slot are actually present, and connect them if so.
Ah now I remember. Qt would compile without complaint, then generate a message on stderr at runtime if it had problems connecting things.
2. Boost does not support inter-thread signals.
thread_safe_signals in the review queue does, although it doesn't have a review manager yet.
I think it's not that. "inter-thread" signals are signals that are send from one thread, and delivered and processed in another thread. I don't think such solution for boost was announced in any form on mailing lists.
See http://doc.trolltech.com/4.3/threads.html#signals-and-slots-across-threads for more details.
Oh, I see. Yes, thread_safe_signals only supports what Qt calls "direct connections" and not "queued connections". - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHe/JW5vihyNWuA4URAqwHAKCxaywAEz6+St9bHO2+DVfld8ZkrwCfa9uy N3/Ou2gOWf1YGPFOmC7dDb0= =jkD3 -----END PGP SIGNATURE-----
So the consensus here is to not use BOOST signals? I could implement the calls another way that would not break when the application becomes multithreaded, which is likely to happen at some point. I would have to implement some sort of queue and lookup an id and then via a pointer trigger the target function along with parameter. Also I noticed that BOOST signals added a cool 300KB to my static lib, strippable to 200KB, which I am not too happy about since this lib's intentions was small size. Any thoughts? j.c. On Jan 2, 2008, at 12:21 PM, Frank Mori Hess wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday 02 January 2008 14:43 pm, Vladimir Prus wrote:
as well as "slots:" and "signals:" pseudo-access specifications for the moc preprocessor to chew on.
Not exactly. In order to 'connect' call to compile, you don't need anything extra at all -- either slot or signal being connected is allowed to not exist in the dynamic type of the objects, or not exist in the static type.
At runtime, connect will check if the signal and slot are actually present, and connect them if so.
Ah now I remember. Qt would compile without complaint, then generate a message on stderr at runtime if it had problems connecting things.
2. Boost does not support inter-thread signals.
thread_safe_signals in the review queue does, although it doesn't have a review manager yet.
I think it's not that. "inter-thread" signals are signals that are send from one thread, and delivered and processed in another thread. I don't think such solution for boost was announced in any form on mailing lists.
See http://doc.trolltech.com/4.3/threads.html#signals-and-slots-across-threads for more details.
Oh, I see. Yes, thread_safe_signals only supports what Qt calls "direct connections" and not "queued connections".
- -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHe/JW5vihyNWuA4URAqwHAKCxaywAEz6+St9bHO2+DVfld8ZkrwCfa9uy N3/Ou2gOWf1YGPFOmC7dDb0= =jkD3 -----END PGP SIGNATURE----- _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Thursday 03 January 2008 12:43, j.c. wrote:
So the consensus here is to not use BOOST signals? I could implement
Noone said that.
the calls another way that would not break when the application becomes multithreaded, which is likely to happen at some point. I would have to implement some sort of queue and lookup an id and then via a pointer trigger the target function along with parameter. Also I noticed that BOOST signals added a cool 300KB to my static lib, strippable to 200KB, which I am not too happy about since this lib's intentions was small size.
I would guess adding Qt would bloat your application even more, as Qt tends to be more "in for a penny, in for a pound" than boost libs. -- Frank
Frank Mori Hess wrote:
On Thursday 03 January 2008 12:43, j.c. wrote:
So the consensus here is to not use BOOST signals? I could implement
Noone said that.
the calls another way that would not break when the application becomes multithreaded, which is likely to happen at some point. I would have to implement some sort of queue and lookup an id and then via a pointer trigger the target function along with parameter. Also I noticed that BOOST signals added a cool 300KB to my static lib, strippable to 200KB, which I am not too happy about since this lib's intentions was small size.
Ouch! Out of curiosity, does compiling with size optimization or disabled inlining has noticable effect on this? In general, it seems like code size was never much of concern inside boost.
I would guess adding Qt would bloat your application even more, as Qt tends to be more "in for a penny, in for a pound" than boost libs.
This is random guess -- if you're really for smallest code size, just grab static version of QtCore and see for yourself. - Volodya
Vladimir Prus wrote:
Frank Mori Hess wrote:
On Thursday 03 January 2008 12:43, j.c. wrote:
So the consensus here is to not use BOOST signals? I could implement Noone said that.
the calls another way that would not break when the application becomes multithreaded, which is likely to happen at some point. I would have to implement some sort of queue and lookup an id and then via a pointer trigger the target function along with parameter. Also I noticed that BOOST signals added a cool 300KB to my static lib, strippable to 200KB, which I am not too happy about since this lib's intentions was small size.
Ouch! Out of curiosity, does compiling with size optimization or disabled inlining has noticable effect on this? In general, it seems like code size was never much of concern inside boost.
Just guessing -- but it's most likely to be RTTI from polymorphic template instantiations: class A { // ... virtual ~A() { } }; template< typename T > class B : public A { // implements abstract A } // ... instantate many B's Now the compiler has to generate RTTI that can't be stripped for every instantiation of the 'B' template, because 'typeid(T)' is guaranteed to return a descriptions of the most derived class in client code of the library. The bloat effect has been observed to be especially severe with GCC. Regards, Tobias
participants (6)
-
Frank Mori Hess -
Frank Mori Hess -
j.c. -
Nat Goodspeed -
Tobias Schwinger -
Vladimir Prus