GNOME Bugzilla – Bug 94765
Gtk::Object is not compatible with smartpointers
Last modified: 2004-12-22 21:47:04 UTC
Gtk::Object is not compatible with smartpointers. a) Glib::RefPtr<> has no operator*() so it's out of question anyway. b) The usage boost::shared_ptr<> has problems with both not manage()ed objects (testsharedptr1.cc) and manage()ed objects (testsharedptr2.cc). In theory it would be possible to support a Glib::RefPtr<> like smartpointer if widgets were not be deleted when a container is destroyed. That wouldn't break existing code since the user would only notice the change when he uses this non-existant smartpointer. However, the changes to gtkmm are non-trivial because there are objects that start with a ref_count > 1 (e.g. GtkButton with a mnemonic).
Created attachment 11378 [details] testsharedptr1.cc: Test boost::shared_ptr<> with not manage()ed Gtk::Label
Created attachment 11379 [details] testsharedptr2.cc: Test boost::shared_ptr<> with manage()ed Gtk::Label
Regarding testsharedptr1.cc: Well of course it doesn't work. Your smartpointer has method scope so it destroys the underlying C++ object when the method ends. If you want the widget to survive as long as the parent then make the smartpointer a class member. Regarding testsharedptr2.cc, I would not expect a smart pointer to work with manage(). You can only use one memory-management system at once. So far, I see no evidence of a bug, but I am happy to be proved wrong.
I don't really expect these examples to work. I want to know how _you_ think one should use boost::shared_ptr<> with gtkmm widgets as you repeatedly suggested. Since I wanted to get rid of the unfruitful discussion on the ml and needed to create some examples anyway, I chose this way. > If you want the widget to survive as long as the parent then make the smartpointer a class member. What parent do you mean? I want the container to hold a strong reference to the widget and other strong references to the same object in my code. I can't see a way to do this or did I miss something in the sentence above? Do you mean I should create my own widget classes inheriting from the gtkmm ones?
boost::shared_ptr<> should be used with gtkmm widgets just as it would for any other C++ class. Your test code would not work with any other C++ class, so it doesn't work with gtkmm. And I'll repeat: Only use one memory management convenience system at once - You can't use both manage() and boost::shared_ptr<> on the same instance because they both expect to control the lifetime. Regarding the "class member": sorry, I expected you to use a derived container. In fact, the shared_ptr would probably be in your main() function, or a global.
You can't use boost::shared_ptr<> like that and expect it to work. Since the gtkmm methods don't take shared_ptr<> as argument this it out of question. Otherwise almost every bit of code out there would be "incompatible" with boost::shared_ptr<>, unless it's using it.
Okay, now at least it is clear what Murray means when he says "use boost::shared_ptr<> if you want the lifetime of your widgets being controlled by a reference counting system". However, since it is a quite complex solution to derive own container types, it is clearly not what I have been looking for, like I already suspected. Anyway, I don't see how this bug report can still be of any use so I agree with "RESOLVED INVALID".