Re: [Vala] Issues will vala and pulse vapi

[Evan Nemerson <evan coeus-group com>]

On Sat, 2015-11-21 at 22:45 -0600, Aaron Paden wrote:
> On Sat, Nov 21, 2015 at 9:54 PM, Evan Nemerson <evan coeus-group com>
> wrote:
> > That's not quite right; the VAPI shouldn't indicate that a *type*
> > is
> > "unmanaged"…  it's up to your code to indicate whether an instance
> > is
> > unowned.  However, the question is really what the proper way to
> > destroy an instance is.
> >
> > In order to determine how to destroy a struct which doesn't specify
> > a
> > destroy_function CCode attribute, Vala will look at the
> > members.  If
> > none of the members require destroy or free functions, then Vala
> > can
> > assume that simply releasing the memory associated with the struct
> > itself (i.e., calling g_free on heap-allocated instances, or simply
> > allowing stack-allocated instances to go out of scope) is
> > sufficient.
>
> Hum. Sourceinfo (and SinkInfo) should not be freed at all, the C APIs
> that retrieve them give you const pointers.

Then they should return an unowned reference.  Note, however, that if
you assign an unowned reference to an owned value, Vala will create a
copy. For example, consider

    unowned string foo = "foo";
    string bar = "bar";
    ...

Discounting things like tmp variables, you'll end up with something
like this in C:

    char* foo = "foo";
    char* bar = g_strdup ("bar");
    ...
    g_free (bar);

With structs the same thing is happening, it's just a bit more
difficult to wrap your head around.

Remember that the C APIs aren't the only way to get a SourceInfo
instance.  You could easily create one yourself.


-Evan