Is Cairo::make_refptr_for_instance() necessary and correct?
Cairo::Refptr and Glib::RefPtr in the unstable master branches are std::shared_ptr aliases. When they became std::shared_ptr aliases, they also became identical. Was that correct? They were not identical before.
glibmm-2.4, before using std::shared_ptr
Glib::RefPtr uses only the ref count in the wrapped C instance, usually a subclass of GObject. It never directly deletes a C++ wrapper. The RefPtr destructor calls unreference(). If the ref count drops to 0, Glib::ObjectBase::destroy_notify_callback_() is called, and it deletes the C++ wrapper. No C instance has more than one C++ wrapper. Glib::wrap_auto() and Glib::ObjectBase::_get_current_wrapper() guarantees that. (If they are used consistently.)
cairomm-1.0, before using std::shared_ptr
Cairo::RefPtr uses the ref count in the wrapped C instance, and its own pCppRefcount_. When a RefPtr is deleted and pCppRefcount_ drops to zero, RefPtr::unref() deletes the C++ wrapper. The C++ wrapper's destructor unrefs the C instance. No callback function is called when the C instance's ref count drops to zero. A C instance can have more than one C++ wrappers.
glibmm and cairomm when using std::shared_ptr
Glib::RefPtr and Cairo::RefPtr are identical, apart from comments. Glib::RefPtr is correct, Cairo::RefPtr is not. The C++ wrappers are never deleted. Both RefPtrs with make_refptr_for_instance() assume that a callback function will delete the C++ wrapper.
Tests with valgrind and gdb
In cairomm master branch there are memory leaks. Destructors are not called. No corresponding problems in cairomm-1.0.
Conclusion
Cairo::make_refptr_for_instance() and Cairo::RefPtrDeleter shall be deleted. std::shared_ptr's default behaviour is what Cairo::RefPtr needs: Delete the C++ wrapper when std::shared_ptr's internal ref count drops to 0. The destructors of Context, Surface, etc, unref the C instance, like they've always done.
@murrayc Have you got any comments?