Re: [Vala] Fail to generate C code for following vala code, is this a bug?

[PCMan <pcman tw gmail com>]

On Sat, Mar 27, 2010 at 3:06 AM, Julian Andres Klode <jak jak-linux org> wrote:
> On Sat, Mar 27, 2010 at 02:37:37AM +0800, PCMan wrote:
> > On Sat, Mar 27, 2010 at 12:17 AM, Julian Andres Klode <jak jak-linux org> wrote:
> > > Well, than f_finish() should probably not be there in the Volume
> > > interface; so I think that's a bug.
> > So how can I fix this? Ship with a custom glib vapi file and remove
> > *_finish from GVolume? Will this work? Or, can you make automatic
> > generation of *_finish optional in Vala, or make the automatically
> > generated *_finish override the abstract method in parent interface if
> > its found?
> It's a bug: https://bugzilla.gnome.org/show_bug.cgi?id=614045
>
> > > > For the second question, if I want to return a unowned GList, it has
> > > > to be owned by the class and cannot be a local variable, right? Would
> > > > you please add this to vala tutorial? I found it not documented and
> > > > this behavior is not easy to figure out. In addition, this is not
> > > > consistent with GObject with C. In C we can create a new GList and
> > > > return it without the need to make it owned by anyone. The callee of
> > > > the function is responsible to free the list.
> > >
> > > Because the list is unowned in can not be local, as it would go
> > > away once the function returns. If you want to return a locally
> > > created object, the return value can only be owned.
> > This is quite different from C and C++ and is hard to understand for a
> > C programmer I think.
> No, it's not. The difference is just that instead of manually freeing
> the returned pointer, the return values are marked as unowned/owned,
> and Vala then adds code to free owned values automatically.
>
> In short, if you have to free a return value in C, it is owned; if
> you don't have to free it, it is unowned.
>
>
> > However, I don't get it. Let take GVolumeMonitor::get_volumes as  example.
> > It returns unowned GLib.List. So if I want to implement that, I should
> > create a list and make it owned by the object instance and then return
> > it unowned. However this is slightly different from the behavior of
> > glib in C. In C GVolumeMonitor::get_volumes returns a
> > "newly-allocated" GList containing a list of GObjects. The caller is
> > responsible to g_list_foreach(list, g_object_unref, NULL); and then
> > g_list_free(list);
> So, the problem is that the function return values are falsely
> marked as unowned in the VAPI. I reported a bug for it at
> https://bugzilla.gnome.org/show_bug.cgi?id=614044
>
> > However, with Vala, how can I make vala methods return a "newly
> > allocated GList" with all objects in it having increased ref_count?
> > Automatic ref couting management in Vala is handy if you only use it
> > in Vala but I find it difficult to make things right when interfacing
> > with C code. I need to check the generated C code to see if it does
> > what I really want. Any better guide for this? Already read Vala
> > tutorial, but I still haven't get it.
> Just don't mark the list as unowned.

But in the glib2 vapi, prototype of that API has 'unowned', but in C,
the returned list should be freed by the caller. So how can I override
this method in correct way?

> --
> Julian Andres Klode  - Debian Developer, Ubuntu Member
>
> See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.