Re: Additional Glib::RefPtr Safety Mechanism

> 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