Re: [sigc] sigc::slot and sigc::trackable
- From: Régis Duchesne <hpreg vmware com>
- To: Chris Vine <chris cvine freeserve co uk>
- Cc: libsigc-list gnome org
- Subject: Re: [sigc] sigc::slot and sigc::trackable
- Date: Mon, 22 Oct 2007 17:13:51 -0700
> I have always assumed (perhaps because it was how I perceived libsigc
> ++1.* to work) that in order for sigc::trackable to operate effectively,
> it was necessary for the slot representing a method of an object derived
> from sigc::trackable to be connected via a sigc::signal object. In
> other words, I had assumed that when an object derived from
> sigc::trackable is destroyed, it would only disconnect any slots
> referring to the object at the sigc::signal level, rather "neutralise"
> the slots themselves.
> However, I have been looking at some of the libsigc++-2 code, and I
> think my assumption was incorrect, since registration with
> sigc::trackable seems to be done by the slot rather than by the signal
> via sigc::slot_rep, and sigc::slot::operator()() tests
> sigc::slot_base::empty() before attempting to invoke the callback.
Correct. Trackables invalidate slots. Trackables and signals have no
However note that slots can be invalidated by trackables in 2 ways:
1) When using the mem_fun kind of slot (as opposed to ptr_fun), a slot
is invalidated if the target class (which implements the member
function) inherits from trackable and is destroyed.
2) When using any kind of slot, a slot is invalidated if an argument
bound to the slot _by reference_ inherits from trackable and is destroyed.
> I know that if a signal is invoked from which all slots have been
> disconnected, it will do nothing (other than, if the callback type would
> return a value, return an object of that return type constructed with
> its default constructor).
Yes. Conceptually, signals are just an array of slots.
> Is it correct that the same true if a slot which represents a method of
> an object derived from sigc::trackable that has been destroyed is
> invoked directly - that is, by calling the slot's operator()() method
> rather than via a signal object?
Yes. If you invoke an invalidated slot by calling its () operator,
I hope it clarifies the matter,
] [Thread Prev