Re: Additional Glib::RefPtr Safety Mechanism
Kjell Ahlstedt via gtkmm-list <[email protected]>
| Newsgroups | gmane.comp.gnome.gtkmm |
|---|---|
| Message-ID | <[email protected]> |
Den 2019-08-30 kl. 11:29, skrev Jonathan Wakely via gtkmm-list: > > > On Thu, 29 Aug 2019 at 21:27, Karsten Pedersen <[email protected] > <mailto:[email protected]>> wrote: > > Hi all, > > One area of C++ that always frustrates me is safety. Smart pointers > such as the Glib::RefPtr go a good way to avoid dangling pointers, use > after free, etc. However one area where this (and std::shared_ptr) is > lacking is that it is very easy for "this" to dangle and there really > is no protection against it. Check out a very simple example here: > > https://github.com/osen/sr1/blob/master/src/tests/dangling_this.cpp > > > Is this actually a common problem that needs to be solved? > > 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. > > 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, 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). /Kjell _______________________________________________ gtkmm-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gtkmm-list