Dear Jonner et al
When you copy a signal, any slots that you connect to the copied signal
will also be triggered when you emit the original signal.
If this is so, I would expect it to work the other way round as well. Does
it? If (after the copy) I connect a slot to the original signal, will
On Thu, 04 Mar 2010 22:46:04 -0600
Jonathon Jongsma jonat...@quotidian.org wrote:
So, I made a rather surprising (to me) discovery the other day. When
you copy a signal, any slots that you connect to the copied signal
will also be triggered when you emit the original signal. Perhaps
this is
On Fri, 2010-03-05 at 10:07 +0100, Mark Roberts wrote:
Dear Jonner et al
When you copy a signal, any slots that you connect to the copied signal
will also be triggered when you emit the original signal.
If this is so, I would expect it to work the other way round as well. Does
it? If
On Fri, 05 Mar 2010 08:27:07 -0600
Jonathon Jongsma jonat...@quotidian.org wrote:
On Fri, 2010-03-05 at 10:07 +0100, Mark Roberts wrote:
Dear Jonner et al
When you copy a signal, any slots that you connect to the copied
signal will also be triggered when you emit the original signal.
On Fri, 2010-03-05 at 14:15 +, Chris Vine wrote:
It is probably better simply to disallow copying of signals, rather
than do shallow copies resulting in the curious effects you mention. I
took that line when writing some signal/slot classes of my own for use
where libsigc++ was not
On Fri, 2010-03-05 at 10:40 -0600, Jonathon Jongsma wrote:
On Fri, 2010-03-05 at 14:15 +, Chris Vine wrote:
It is probably better simply to disallow copying of signals, rather
than do shallow copies resulting in the curious effects you mention. I
took that line when writing some
On Fri, 05 Mar 2010 10:40:52 -0600
Jonathon Jongsma jonat...@quotidian.org wrote:
On Fri, 2010-03-05 at 14:15 +, Chris Vine wrote:
It is probably better simply to disallow copying of signals, rather
than do shallow copies resulting in the curious effects you
mention. I took that
2010/3/5 Chris Vine ch...@cvine.freeserve.co.uk:
It is probably better simply to disallow copying of signals, rather
than do shallow copies resulting in the curious effects you mention.
Yes - under no circumstances should signals be copyable. This is what Boost did.
By the way, is using
How about using Boost signal2 lib ?? . Its thread safe also .
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
On Fri, Mar 5, 2010 at 2:18 PM, sankar bose shankarbose@gmail.com wrote:
How about using Boost signal2 lib ?? . Its thread safe also .
As far as I know, boost doesn't guarantee any API / ABI stability for
this this or any of its other libraries. So even if we wanted to use
it, we couldn't
On Fri, 2010-03-05 at 17:51 +0100, Murray Cumming wrote:
On Fri, 2010-03-05 at 10:40 -0600, Jonathon Jongsma wrote:
On Fri, 2010-03-05 at 14:15 +, Chris Vine wrote:
It is probably better simply to disallow copying of signals, rather
than do shallow copies resulting in the curious
On Sat, 6 Mar 2010 01:48:05 +0530
sankar bose shankarbose@gmail.com wrote:
How about using Boost signal2 lib ?? . Its thread safe also .
boost::signal2 is a fine library which is very versatile indeed and
also claims thread safety. I considered using it instead of going
through the
So, I made a rather surprising (to me) discovery the other day. When
you copy a signal, any slots that you connect to the copied signal will
also be triggered when you emit the original signal. Perhaps this is
better explained by the following code:
=
#include iostream
On Thu, 2010-03-04 at 22:46 -0600, Jonathon Jongsma wrote:
this means that any classes containing sigc::signals
that don't want their signals to be triggered when their copies are
emitted *must* define a custom assignment operator and copy
constructor
that intentionally doesn't copy these
On Thu, 2010-03-04 at 22:46 -0600, Jonathon Jongsma wrote:
any slots that you connect to the copied signal will
also be triggered when you emit the original signal
Sorry, I had misunderstood. Yes, this is a bit strange.
--
murr...@murrayc.com
www.murrayc.com
www.openismus.com
15 matches
Mail list logo
