Re: Abstract string properties with getter/setter functions
- From: Raffaele Sandrini <raffaele sandrini ch>
- To: Tim Janik <timj gtk org>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: Abstract string properties with getter/setter functions
- Date: Thu, 20 Sep 2007 08:34:21 +0200
On Wed, 2007-09-19 at 19:17 +0200, Tim Janik wrote:
> >>> 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
> $
Take a look at 'gtk_file_chooser_get_preview_widget'. While the hack
done there is somehow possible with objects it is not with strings.
GtkWidget *
gtk_file_chooser_get_preview_widget (GtkFileChooser *chooser)
{
GtkWidget *preview_widget;
g_return_val_if_fail (GTK_IS_FILE_CHOOSER (chooser), NULL);
g_object_get (chooser, "preview-widget", &preview_widget, NULL);
/* Horrid hack; g_object_get() refs returned objects but
* that contradicts the memory management conventions
* for accessors.
*/
if (preview_widget)
g_object_unref (preview_widget);
return preview_widget;
}
>
> > 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).
That might be true but does not help here. We use getters/setters all
through Vala for several reasons including the ability to embed a
getter/setter in any kind of C expression and due to speed concerns with
GValue. The memory convention of getters/setters is to return "weak"
references.
Therefore we think, using virtual setter/getter for virtual/abstract
properties would be a solution, but I'd hoped you have a more simple
one ;).
cheers,
Raffaele
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]