Boost Users :
From: j.c. (jolix_at_[hidden])
Date: 2008-01-03 12:43:23
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.
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
>> extra at all -- either slot or signal being connected is allowed to
>> 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
>> 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
>> from one thread, and delivered and processed in another thread. I
>> think such solution for boost was announced in any form on mailing
>> for more details.
> Oh, I see. Yes, thread_safe_signals only supports what Qt calls
> connections" and not "queued connections".
> - --
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> -----END PGP SIGNATURE-----
> Boost-users mailing list
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net