Am 05.10.2012 11:32, schrieb klaus triendl: > Am Fri, 05 Oct 2012 10:38:20 +0200 > schrieb Kjell Ahlstedt <kjell ahlstedt bredband net>: > >> All this seems incredibly complicated. Bug 495762 mentions an easier >> way. See especially comment 9. >> >> https://bugzilla.gnome.org/show_bug.cgi?id=495762#c9 >> >> It's cryptic. I haven't tested it myself, but I suppose someone else >> has. >> >> Glib::RefPtr<MyClass> c; >> ... >> button.signal_clicked().connect(sigc::mem_fun(c.operator->(), >> &MyClass::on_button)); > > The problem with my code is that Glib::RefPtr doesn't have a > dereferencing operator. Sorry, I didn't take this into account when I > used shared_ptr. > > 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? 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? Regards, Florian Philipp
Attachment:
signature.asc
Description: OpenPGP digital signature