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? Chris _______________________________________________ libsigc-list mailing list libsigc-list@gnome.org http://mail.gnome.org/mailman/listinfo/libsigc-list