On Sat, 2015-11-21 at 23:37 -0600, Aaron Paden wrote:
> On Sat, Nov 21, 2015 at 11:07 PM, Evan Nemerson <e...@coeus-group.com
> > wrote:
> > 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.
> 
> Is it possible to do this when the pointer is an argument? These
> types
> are requested and then asynchronously retrieved via callbacks.

Arguments are unowned by default.  Just don't copy it into an owned
variable and you should be fine.

Looking at your original example, it looks like you create a
Gee.ArrayList<PulseAudio.SourceInfo?>.  Try Gee.ArrayList<unowned
PulseAudio.SourceInfo?>.

That said, I have no idea if you can count on the SourceInfo instances
surviving past the end of the callback invocation.  If it doesn't you
probably need to create a copy of the whole struct, and you're back at
the issue of how whether the various fields should be owned or not,
which is something I can't answer.
_______________________________________________
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Reply via email to