Re: [Vala] ownership passing problem...

[Jiří Zárevúcky <zarevucky jiri gmail com>]

2009/7/13 Fredderic <magentus gmail com>:
> To the wonderful wizards of Vala...  I need some help...  I have an
> object that presents certain information in a dialog.  Other instances
> of that object also share the same dialog.  Nothing else in the program
> needs to know that the Dialog even exists, it will manage its own
> lifetime.
>
> I assume the following two issues are simply that I just don't
> understand how to tell Vala about my intentions regarding object
> ownership...  Starting with the line:
>
>    new EventNotifier(this,
>        new Gtk.TreeRowReference(store, store.get_path(iter)));
>
> Unfortunately, this doesn't work.

It's a wild guess, but you can try assigning it to a pointer.

EventNotifier* tmp = new EventNotifier ...

But I didn't actually try it.

> - How to create an instance EventNotifier, without keeping a reference
>  to it (its lifetime is tied to a dialog which the caller doesn't
>  know about).  That line fails because it's not being assigned to a
>  variable, and assigning it to a temporary variable results in this
>  error: "local variable 'blah' declared but never used"
>
> - How to create and pass ownership of a Gtk.TreeRowReference to another
>  object.  Gtk.TreeRowReference is a "compact class", if I understand
>  Vala terminology, and Vala seems to insist on wanting to copy the
>  instance.  All I want to do is create it using local knowledge, and
>  then hand it off.  No copying, no unref'ing, just pass a pointer.

You can transfer ownership by using the "(owned)" operator.

Example:
var local1 = new CompactObject ();
var local2 = (owned) local1;    // local2 now holds the object and
local1 is null

Works the same with "return" instead of variable. You can transfer the
reference of counted objects the same way.

> I've looked at the source produced by Vala, and it seems to do an
> incredible amount of temporary variable fiddling.  For instance, one
> that's been bugging me that I can't seem to work around;
>
>        Gtk.TreeIter iter;
>        events.store.get_iter(out iter, rowref.get_path());
>
> The second line gets wrapped with freaky temporary variable magic.  It
> creates a temporary variable, stores the iter into that, then if the
> original iter is not null, free's it (it'll ALWAYS be null here), and
> then assigns the iter stored in the temporary variable into iter.  I
> can't remember if it was this instance, or another one, but I beleve
> all that to, only happens if the temporary variable wasn't set to
> null by get_iter(), which I also already know is not possible in the
> context of that line anyhow.
>
> Or is the C compiler supposed to recognise this situation and optimise
> out all that temporary variable fussing?  Or is there another way to
> use an out parameter like that which is more informative to Vala, so
> that it can simply pass the address of the iter and be done with it.

Yes, the compiler does create an enormous amount of temporary
variables. I'm afraid that won't change in a foreseeable future, as
it's largely just a cosmetic flaw.

> --
> Fredderic