On Thu, 2010-03-25 at 10:52 +0000, Chris Vine wrote: > On Thu, 25 Mar 2010 09:46:08 +0100 > Murray Cumming <[email protected]> wrote: > > On Thu, 2010-03-25 at 01:57 +0000, Chris Vine wrote: > > > In cases where GTK+ does not in fact > > > intend ownership to be passed, gtkmm gets round this by incrementing > > > the reference count in the getter function, thus neutering the > > > RefPtr, but also leaving open the possibility of a reference being > > > owned by a user to an invalid object. In such cases the object > > > should really be returned by a simple pointer or a weak pointer. > > > > Do you have an example GTK+ C function for that? Maybe it should even > > be in gtkmm's bugzilla. > > I am thinking of all those GTK+ getter functions where the user is > not expected to call g_object_unref() when finished with manipulating > the return value. These objects are usually owned by another GTK+ object > (the one whose method the getter function is) and will have parts of > their implementation which become invalid when the owner is finalised > (they are expected to be destroyed at the same time). > > Particularly obvious examples are manager classes such as a > GtkTreeSelection object, which is owned by a GtkTreeView object. It > is part of the TreeView's implementation and is completely invalid when > the TreeView no longer exists.
What would some application code look like if you fixed this in the gtkmm API? -- [email protected] www.murrayc.com www.openismus.com _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
