Re: [gtkmm] Glib::RefPtr construction

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.


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


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



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

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