Re: Abstract string properties with getter/setter functions

["Michael Lawrence" <lawremi iastate edu>]

On 9/19/07, Raffaele Sandrini <raffaele sandrini ch> 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