2009/7/13 Fredderic <[email protected]>:
> 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
>
_______________________________________________
Vala-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/vala-list

Reply via email to