[sigc] sigc::slot and sigc::trackable
- From: Chris Vine <chris cvine freeserve co uk>
- To: libsigc-list gnome org
- Subject: [sigc] sigc::slot and sigc::trackable
- Date: Fri, 12 Oct 2007 11:29:44 +0100
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.
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).
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?
] [Thread Prev