Re: Additional Glib::RefPtr Safety Mechanism

Den 2019-08-30 kl. 11:29, skrev Jonathan Wakely via gtkmm-list:

On Thu, 29 Aug 2019 at 21:27, Karsten Pedersen <kpedersen gmx com> 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:

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" (


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]