Re: sigc::mem_fun and Glib::RefPtr

[klaus triendl <klaus triendl eu>]

Am Fri, 05 Oct 2012 12:27:01 +0200
schrieb Florian Philipp <lists binarywings net>:

> Am 05.10.2012 11:32, schrieb klaus triendl:

> > Yes, it's easier but all you do is to fetch the c-pointer from the
> > RefPtr. But you loose the reference counting: if the variable 'c'
> > goes out of scope you end up with a dangling pointer when there
> > isn't any other RefPtr alive.
> > 
> > 
> > A much easier solution than I've posted before is the following:
> > 
> > sigc::slot<void> f = 
> >     sigc::group(&MyClass::on_button, 
> >                 sigc::group(&std::shared_ptr<MyClass>::operator->,
> > c)); f();
> > 
> 
> Would there still be a dangling pointer if MyClass extends
> sigc::trackable (by being a Glib::Object, for example)? Or would you
> need to use sigc::ref for this?

You're right, deriving from sigc::trackable prevents a dangling pointer
because slots are invalidated when trackables are destroyed and
disconnected from signals.

> In either case it is mostly a matter of semantics: Do you want to keep
> the connection until the object is no longer referenced or do you want
> to keep the object until the connection is removed?

This is a good way to look at the problem!




btw the trackable mechanism doesn't work if we bind the object instance
to a member function:
sigc::slot<void> f = sigc::bind(&MyClass::on_button, c.get());
the same goes for lambda parameters.

is this intended or a bug?



regards,
klaus