On Wed, 19 Sep 2007, Raffaele Sandrini wrote: > On Wed, 2007-09-19 at 17:53 +0200, Tim Janik wrote: >> On Wed, 19 Sep 2007, Raffaele Sandrini wrote:
>> callers of getters have to free the returned string in C. >> for glib/gtk programs, if the caller doesn't need to free the string, >> the return value should be G_CONST_RETURN gchar*. > > That's right since the getters do not claim ownership they do not need > to free the strings. The problem is the caller assumes a weak reference > and will dup it if it needs ownership. > The point here is that we are talking about *abstract* properties i.e. i > do not know whether the implementation uses a static string or not. I > have to call g_object_get whether i want to or not. i'm not quite sure why you'd *not* want to call g_object_get if you want to get the property ;) btw, if you're autogenerating code, you should be better off with using g_object_get_property() which is more efficient than g_object_get() to use, especially if the caller doesn't mind initializing and unsetting his own GValue. >>> Since we do not see a way around this (yet) and we could not find an >>> example with strings in another project. I'm asking here if there is a >>> nice way around this. >> >> i'm really not sure i understand your problem here... > > We need a way to steal the string from the property i.e. to make sure > its not a copy of the original. well, why do you want to peek at the original string at all? there's no API with which you'd ever be allowed to modify such a string pointers contents, so always getting a copy should be no problem for you. >>> BTW: There are equal issues with properties returning objects only there >>> you can add a hack into the getter unrefing the object before returning >>> it. This is not applicable with strings. >> >> this is not applicable with objects. as soon as you called unref(obj), >> the object will be destructed and gone, you can't hand it on any further, >> "obj" will point to freed memory. >> in some rare cases and if you're lucky, the object might stay around >> a little longer because someone else could coincidentally hold another >> reference. but this can't be relied upon. >> a well formed getter implementation might do: >> return g_object_ref_sink (g_object_new (MY_TYPE_DATA_OBJECT, NULL)); >> once you g_object_unref() this return value, it'll be instantly vaporized >> with >> a crushing noise (if you hooked up pulseaudio via destruction emission hooks >> ;) > > You can check the ref count first. erm, no. that's at least not a clean solution, ref counts may increase and decrease at any point in time for random reasons (caches, garbage collection algorithms, etc...), even from concurrently running threads without holding the GDK lock. > Take a look at the GtkFileChooser interface > there this hack is used several times. (and annotated as such) hm, not here: $ fgrep ref_count gtk/gtkfilechooser*.c $ > All we need from you is either a solution or the statement that this is > not possible with gobject properties ;). i don't quite get what you're trying to achive. but if efficiency is your only concern, i do think that you can spare a string copy by using g_object_get_property() instead of g_object_get(). it just still will be internally copied when it's passed around as a GValue (g_object_get just does two copies alltogether, the second of which needs to be freed by tha caller). > Forgot to post the bug against Vala: > http://bugzilla.gnome.org/show_bug.cgi?id=472904 > > Hope things are more clear now. > > cheers, > Raffaele > --- ciaoTJ _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
