Re: [gtkmm] Glib::RefPtr construction

Murray Cumming wrote:
On Wed, 2003-01-08 at 16:45, Michael Johnson wrote:

One consequence of this paradigm shift would be that the
destroy_notify_callback in Glib::ObjectBase would no longer result in
deletion of the wrapper.

When the GTK+ object dies, the C++ object must die. Their lifetimes must
be linked to keep things simple. So far that has worked fine.
I believe that this will happen appropriately with a 'correct' implementation of reference counting. So long as the C++ object is alive and holds a reference to it, the GTK+ object should not be destroyed. When the C++ object is destroyed and releases its reference, then the GTK+ object *may* be destroyed, if there are no other references to it being held by other C objects.

The current implementation works by keeping the GTK+ object alive at least as long as there are references to the C++ object. That should remain the case in the implementation I described, but hopefully in a greatly simplified manner.
I don't think you'll be able to make RefPtr
do the right thing always by writing perfect constructor and operator=()
implementations, because GTK+ does not have a consistent
reference-counting policy. We need to generate specific generated code
(e.g. see refreturn in the .hg files). As I said before, by doing so, we
hide the GTK+ inconsistencies. 
Is there someplace where these inconsistencies are documented, or do I need to go searching through the GTK+ documentation?
RefPtr<> is not intended for this purpose. RefPtr is for use with
Glib::Object-derived objects only.
The documentation does not make this distinction.
OK, we should fix the docs.
I was thinking more along the lines that the docs are correct and the implementation needs to be changed, actually. I note that there are already classes in gtkmm (see Glib::IOChannel) that are derived directly from SigC::Object that are nonetheless managed using Glib::RefPtr.



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