On 9/19/07, Raffaele Sandrini <[EMAIL PROTECTED]> wrote:
>
> 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.
It's difficult to imagine how one would enforce this, given that the
implementation has complete freedom to copy the string. The GOB string
getters always returned an allocated string. I'm afraid you may have to
resort to that in general.
>
> > > 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
>
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
