Re: [Boost-users] [signals] calling delete member on connect?

From: Sebastian Redl (sebastian.redl_at_[hidden])
Date: 2006-02-05 13:13:19

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