Re: [Vala] Generating bindings for non-GLib/GObject based API

[Michael Wild <themiwi users sourceforge net>]

On 23. Apr, 2010, at 22:29 , Jan Hudec wrote:

> On Fri, Apr 23, 2010 at 09:36:18 +0200, Michael Wild wrote:
> > Another thing where I'm not sure how to best solve it: The basic C-type I'm
> > using is a typedef to a pointer whose base-type is implementation dependent
> > (i.e. unknown). E.g. like this:
> >
> > typedef struct unknown_type* Thing;
> >
> > Now, in my small test cases, I used the following for the binding:
> >
> > [SimpleType]
> > [CCode (cname = "Thing", cheader_filename = "thing.h", free_function = "free")]
> > struct Thing {
> >  [CCode (cname = "create_thing")]
> >  private static int create_imp(Thing* self, int a, int b, double c); 
> >  [CCode (cname = "create_thing_wrapper")]
> >  public static Thing create(int a, int b, double c) {
> >    Thing self;
> >    int stat = create_imp(&self, a, b, c); 
> >    return self;
> >  }
> >
> >  [CCode (cname = "print_thing")]
> >  public void print();
> > }
> >
> > This compiles and runs, but Vala now (quite understandably) thinks that
> > Thing is a value-type and doesn't call free() on it. AFAIK for this to
> > happen I'd need to change Thing to be a of compact class type, but then
> > everything else would break because Vala starts passing the object around
> > as a pointer (i.e. resulting in unknonw_type**, where unknown_type* is
> > expected).
>
> Actually I believe
>
>    [Compact]
>    [CCode (cname = "void", ...)]
>    class Thing ...
>
> should work. It will give you void * passed around, so it's some kind of
> pointer and C implicitly casts to and from void *, so no errors and no
> warnings.

I don't think that I'd like that one particularly... I'd rather prefer to use a Vala wrapper class then.

> You can also just make it
>
>    [Compact]
>    [CCode (cname = "struct unknown_type", ...)]
>    class Thing ...
>
> with the real value for "unknown_type" from the library header. That will
> make the code more type-safe on the C side, but vala will check the types
> enough and it would be relying on something not officially documented.

Unfortunately that's impossible. The official standard states that there is a opaque type Thing, but nothing 
more. Every implementor is free to do as he pleases... Some even typedef it to an integer handle.

> You may also need to set the [CCode(copy_function=...)] or explicitly tell
> vala that it can't be copied via [CCode(has_copy_function=false)].
>
> On a side note, structs normally have destroy_function rather than
> free_function, but I am not sure there is a difference.

Noted.

Michael