Am 05.10.2012 11:32, schrieb klaus triendl: > Am Fri, 05 Oct 2012 10:38:20 +0200 > schrieb Kjell Ahlstedt <[email protected]>: > >> 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ gtkmm-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gtkmm-list
