Created attachment 123600 [details] [review]
GValue example

Comment on attachment 123600 [details] [review]
GValue example

>Index: tests/everything/everything.c

>+ * @v: (transfer none): a GValue expected to contain an int

>+int test_int_value_arg(const GValue *v) {
>+  int i;
>+
>+  i = g_value_get_int (v);
>+
>+  return i;

Transfer looks correct here.

>+static const GValue value;
>+/**
>+ * test_value_return:
>+ * @i: an int
>+ *
>+ * Return value: (transfer none): the int wrapped in a GValue.
>+ */
>+const GValue *test_value_return(int i) {
>+  g_value_init (&value, G_TYPE_INT);
>+  g_value_set_int (&value, i);
>+
>+  return &value;
>+}
>+

This function is leaking the GValue if you call it more than once, no?
I think it would be a better example to allocate the GValue on the heap and
mark the transfer as container or full.
Not sure if the GValue should be treated as a container or not, my gut feeling is that it should.

(In reply to comment #2)
> (From update of attachment 123600 [details] [review] [edit])
> >Index: tests/everything/everything.c
> 
> >+ * @v: (transfer none): a GValue expected to contain an int
> 
> >+int test_int_value_arg(const GValue *v) {
> >+  int i;
> >+
> >+  i = g_value_get_int (v);
> >+
> >+  return i;
> 
> Transfer looks correct here.
> 
> >+static const GValue value;

hmm I should remove the const here

> >+/**
> >+ * test_value_return:
> >+ * @i: an int
> >+ *
> >+ * Return value: (transfer none): the int wrapped in a GValue.
> >+ */
> >+const GValue *test_value_return(int i) {
> >+  g_value_init (&value, G_TYPE_INT);
> >+  g_value_set_int (&value, i);
> >+
> >+  return &value;
> >+}
> >+
> 
> This function is leaking the GValue if you call it more than once, no?

Am I? I'm using a static variable, always the same

> I think it would be a better example to allocate the GValue on the heap and
> mark the transfer as container or full.

The problem with this is that the caller wouldn't know how to free it (there is no g_value_free

> Not sure if the GValue should be treated as a container or not, my gut feeling
> is that it should.
> 

No, but there is a g_value_unset.

I don't think anyone uses a const GValue return, do they?  There are only a few limited patterns for GValues in my experience.

Seems like quite a few do:

johan@cotovia:/usr/include$ find -name \*.h|xargs grep "const GValue"| wc -l
211
johan@cotovia:/usr/include$ find -name \*.h|xargs grep "GValue"| wc -l
568

So I guess it would make sense.

(In reply to comment #6)
> Seems like quite a few do:
> 
> johan@cotovia:/usr/include$ find -name \*.h|xargs grep "const GValue"| wc -l
> 211
> johan@cotovia:/usr/include$ find -name \*.h|xargs grep "GValue"| wc -l
> 568
> 
> So I guess it would make sense.
> 

I guess these are mostly const GValue passed as argument, not returned.


Our usecase is quite specific, we use const GValue as the return value for a const GValue *ResultSet::getField method in our DB wrapper, where the GValue are owned by the object. If you think this is too specific I could move this test to gjs.

The test_value_return doesn't leak I think, since the value is set to an int unset doesn't release anything.

(In reply to comment #7)
> Our usecase is quite specific, we use const GValue as the return value for a
> const GValue *ResultSet::getField method in our DB wrapper, where the GValue
> are owned by the object. If you think this is too specific I could move this
> test to gjs.

This is essentially the same as glib's:

GValue*		g_value_array_get_nth	     (GValueArray	*value_array,
					      guint		 index_);

except that glib doesn't specify const (but it *is* (transfer none)). So it's not totally crazy.

Your example test function *is* totally crazy though :-).

Of course there are lot of functions like this in GLib in particular, the question is are they interesting to bind automatically?

GValue in general seems like something one would want to treat specially in a binding, thus transitively GValueArray.

Committed (with a fix to reset to GValue to 0)

[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]