Am Fri, 05 Oct 2012 12:27:01 +0200 schrieb Florian Philipp <[email protected]>:
> 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 _______________________________________________ gtkmm-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gtkmm-list
