GValue difficulties

[rainwoodman]

GValue gives a nice api, but

1. the 'data' element of GValue is private

2. Vala cannot cast GValue to a type generics

3. Can we add new GType, BinaryRepresentation, and register transform functions that converts any GType to a binary representation. Then g_value_get_binary_rep() gives a pointer.

[arteymix]

We should use GValue exclusively for type transformations and write a helper to extract a pointer to the memory held within it.

The thing is, we don't need to do unnecessary copies into a new GType container. We just need to get a pointer on either the data union or the v_pointer field itself.

This can be done with a small helper that checks whether the type is boxed. We can use the following functions:

• http://www.valadate.org:8000/#!api=gobject-2.0/GLib.Value.fits_pointer
• http://www.valadate.org:8000/#!api=gobject-2.0/GLib.Value.peek_pointer

[arteymix]

Yeah, peek_pointer is used to get a pointer on the data field I believe.

[rainwoodman]

Nope. I tried it. peek_pointer tries to view the memory as a pointer; it is not getting the pointer to the data element.

[rainwoodman]

So if the GValue holds a float, it actually dies with a g_critial due to fits_pointer. My proposal is

   ..... (Value value) {
       Value conv = Value(array.scalar_type);
       value.transform(ref conv);
       Value buf = Value(BufferType); 
       buf.transform(ref buf);  /* data[0] stores a pointer to data[1], data[1] stores the byte stream. We shall register BufferType fits_pointer is true. */
       void * buf = buf.peek_pointer();
       Mem.copy(array.data + offset, buf, array.elsize);

[arteymix]

I'll check that. First we need to support all GLib basic types and then deal with Numeric-GLib and then deal with user types.

[rainwoodman]

This seems to be no longer relevant. looks like we decided any API that goes through GValue is by definition slow and we can pretty much do what ever it takes to get the semantics right.

[arteymix]

The data field is not private: there's just no concept of union in Vala. I fixed this in 07d5c4cb7198efca029a6c4ff3f14a37c96dc412 by writting a C implementation of _value_get_data.

The GValue thing is only a convenience over the pointer API. It's also essential for bindings. From a scalar perspective, it's not inefficient and we should simply not recommend looping with get_value or set_value.

I can close this because we now have full support :+1: