Re: [gtkmm] Glib::RefPtr construction

[murrayc t-online de (Murray Cumming)]

On Wed, 2003-01-08 at 16:45, Michael Johnson wrote:
> What I am proposing, which I guess did not come through clearly, is
> that gtkmm objects should initialize their reference count to zero,
> not to one.

GTK+ objects with a zero reference count of 0 are unusable/dead/invalid.

> It appears, from reading further on, that the reference counting of
> gtkmm objects is being treated as being synonymous with the reference
> counting of the GTK+ objects that they are wrapping. To me, this seems
> wrong. The gtkmm object and the GTK+ object it is wrapping are not in
> fact the same entity. One is merely a proxy for the other. It would be
> better for the gtkmm object to be reference counted in its own right,
> and for the reference count of the GTK+ object to be incremented only
> when the gtkmm wrapper acquires a reference to it

Remember what I said about GKT+ objects being created with a reference
count of 1.

> , and decremented only when the gtkmm wrapper releases a reference to
> it.

That sounds possible, though it doesn't seem to add any features, though
it _might_ allow use of RefPtr<> with Gtk::Widgets.

Feel free to patch glibmm 2.4 in the glibmm module.

[snip]

> 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.

[snip]

> Since it appears that GTK+ uses COM-style reference counting protocol
> (i.e. anything that passes a pointer to an object to some other entity
> increases the reference count before handing out the pointer) it
> really only becomes necessary for Glib::ObjectBase to decrease the
> gobj reference count at the appropriate time. However, I'd want to
> verify this assumption before writing code based on it.

We use gobj_copy() for this. 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. 

> > RefPtr<> is not intended for this purpose. RefPtr is for use with
> > Glib::Object-derived objects only. If you can add some code to prevent
> > the template from compiling with anything else then I would welcome the
> > patch.
> >   
> The documentation does not make this distinction. It says that RefPtr
> is a reference-counting smart pointer, and that it will work with any
> class that has reference() and unreference() methods, *such as* a
> Glib::ObjectBase-derived class. As such, it should behave in ways that
> a general reference-counting pointer would be expected to behave. This
> is, I think, as it should be.

OK, we should fix the docs.

> I would be happy to put together a patch that demonstrates how I think
> RefPtr and the classes in gtkmm should behave. Perhaps that would more
> clearly illustrate what I'm trying to express.

Yes.

[snip]

Please try to be concise and avoid repetition. I'm sure that most people
have not read this thread because it contains so much text.

-- 
Murray Cumming
murray usa net
www.murrayc.com