Ok i see there is need to clarify things. On Wed, 2007-09-19 at 17:53 +0200, Tim Janik wrote: > On Wed, 19 Sep 2007, Raffaele Sandrini wrote: > > > Hi there, > > > > While implementing abstract properties in Vala we encountered a problem > > regarding string properties with getter and setter functions: > > > > public interface Test.MyIface { > > public abstract string text { get; } > > } > > > > A getter function of an abstract string property looks like: > > char* test_my_iface_get_text (TestMyIface* self) { > > char* value; > > g_object_get (G_OBJECT (self), "text", &value, NULL); > > return value; > > } > > > > Property accessors in Vala always return weak references. This leads to > > a memory leak in the calling function of the getter. > > i'm not sure what you mean with weak/strong references when it > comes to strings. in C, pointers can be handed out which point to > 0-terminated char arrays that represent strings. there's on reference > counting for strings in C as there is in C++. per convention, > for glib/gtk programs, some such string pointers must be g_free()-ed once.
With strong/weak references is talk about ownership. If some code needs ownership over a string it will dup the string. > > 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. > > > We want property accessors to return weak references so just redefine > > the accessors to return a strong reference is only a last-resort-option. > > requesting that all string return types should be const char* is technically > not possible, because some strings need to be constructed in getters. > > people who don't want to deal with these memory allocation issues (const > strings vs. caller-needs-to-free strings) should stay away from C, maybe > even C++, and use python, java, scheme, other-garbage-collected languages. Vala needs to deal with this issues to enable users who do not want to deal with it an easy life. > > > 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. > > > 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. Take a look at the GtkFileChooser interface there this hack is used several times. (and annotated as such) All we need from you is either a solution or the statement that this is not possible with gobject properties ;). Forgot to post the bug against Vala: http://bugzilla.gnome.org/show_bug.cgi?id=472904 Hope things are more clear now. cheers, Raffaele _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list