Additional Glib::RefPtr Safety Mechanism

Karsten Pedersen <[email protected]>
Newsgroups gmane.comp.gnome.gtkmm
Message-ID <[email protected]>
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

Would it interest the gtkmm project to safeguard against this? I have
prototype code (in the same repository linked above) that augments a
basic shared_ptr implementation with an "operator->" that locks the
smart pointer until it has returned.
If error such as the one above occurs it immediately aborts and
notifies the developer that things are wrong.

I have devised systems to perform the same "locking" mechanism that can
be used with *ptr, std::vector::at and iterators. Again in that same
repository you can see a number of test cases that are protected
against.

In particular I can see this being really nice to enable in "debug"
builds. Then upon a release build there is absolutely no additional
overhead (because all this extra instrumentation has been stripped
out).

What do you guys rekon? Is this idea of interest?

Best regards,

Karsten
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.