Evan Carew wrote:
Hmm, have you even used signals before? The manual for it was the basis of my example program. I don't think you would have said that if you had used the library before.
Which part of the manual? I have used Signals before, but I admit that I've never been in a situation where the destructor of my signal would have been relevant. Nevertheless, I'm very curious as to what prompted you to assume that I haven't used the library. I'm browsing the docs right now, and there is hardly any mention of what happens with the slot object, beyond that it's passed to connect() by const reference. This does not, however, mean that it is stored internally as a reference. In fact, since the const reference allows you to pass a temporary, such behaviour would be catastrophic. The first block of the design overview, "Type Erasure", hints that Signals stores the slot objects as Boost.Function objects. So let's go to that library's documentation and see what they have to say on the matter. Boost.Function says, in the documentation of functionN::functionN(F):
*Postconditions*: |*this| targets a copy of |f| if |f| is nonempty, or |this->empty http://www.cppdoc.local/boost/doc/html/functionN.html#id1001382-bb()| if |f| is empty.
In other words, the object is copied into the Function, not referenced. The tutorial also states that if you wish that no copying is done, you should use boost::ref or boost::cref to wrap the object. Internally, Signals will then proceed to store the function object somewhere. It is not unreasonable to assume that four temporary copies of the Function object are created. And as functionN::functionN(const functionN&) states:
*Postconditions*: Contains a copy of the |f|'s target, if it has one, or is empty if |f.empty http://www.cppdoc.local/boost/doc/html/functionN.html#id1001382-bb()|
Again a copy of your own object will be created. Thus, when temporary Function objects get created, temporaries of your type are also created. And destructed again, calling the destructor of your object. (On a side note, I would recommend against calling it the "delete function". Delete has a very specific meaning in C++, and while it has something to do with destructors, it's still something entirely different.) So, on to the solution of your problem that you asked for in the other mail. Solution 1) Don't depend on the destructor of your slot object. Slot objects should be largely trivial. I would recommend this solution. Solution 2) If you really HAVE to depend on the destructor (say, because for some reason you have a big, stateful slot object), you can follow Function's tutorial and wrap the object in a boost::ref or boost::cref. Sebastian Redl