> I agree with Jonathan. Karsten, is this a problem you have actually > seen in a program using Glib::RefPtr? Usually data of type > Glib::RefPtr<SomeClass> are protected or private members of a class,
I originally developed this "safety" library for my students to use as a teaching aid (and get immediate feedback of errors if they do something wrong rather than having to debug a corrupted heap). So, yes, I did see this issue fairly commonly with newer or beginners developers to C++. I understand this possibly isn't the gtkmm developer "target market" but I could also imagine it being fairly common in larger projects with complex hierarchies of objects (such as perhaps GUI toolkits) and especially ones involving callbacks. Wrapping a fiddly C library like mongoose http server (https://github.com/cesanta/mongoose) comes to mind; the disconnect callbacks end up triggering *after* the server object goes out of scope, leaving potential opportunity for use after delete with "this" if you remove the current connection from any std::vectors at that point and it is the last reference count. I have yet to see it in any gtkmm code (you will be pleased to hear) but my personal opinion is that it is surely a nice idea to attempt to make C++ 100% safe rather than having to rely purely on the skills of a developer. This is generally the trend in Rust communities but it seems the culture in C++ communities is that not all safety is necessary. > > It seems like a solution in search of a problem. IMO you should > > just avoid using globals like this when possible, and use them > > carefully when necessary. Admittedly the example I crafted was part of my regression tests so was deliberately "dumb", however even if an object isn't global, for example it could be the last reference count contained within a structure passed as user data into a button click callback. If that carelessly gets blown away, "this" gets subsequently used; you are running into undefined behaviour. > or local data in a function. An almost opposite problem has been > reported, though: How do you get a RefPtr to "this" > (https://gitlab.gnome.org/GNOME/glibmm/issues/8). I am guessing this is similar to what the std::enable_shared_from_this<T> facility is for in std. Feels a bit messy but that is just how C++ is I suppose ;) No worries if you don't feel this is necessary, just thought I might put the idea out there. Karsten _______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
