On Sun, 2008-12-21 at 00:16 +0100, Jürg Billeter wrote:
> On Sat, 2008-12-20 at 23:57 +0100, Hans Vercammen wrote:
> > On Sat, 2008-12-20 at 08:24 +0100, Jürg Billeter wrote:
> > > On Sat, 2008-12-20 at 02:19 +0100, Hans Vercammen wrote:
> > > > On Fri, 2008-12-19 at 12:10 +0100, Jürg Billeter wrote:
> > > > >
> > > > > * `unowned' type modifier complements `weak' type modifier
> > > > >
> > > > > `weak' only make sense for reference fields, list elements, and local
> > > > > variables to break reference cycles. Vala will use
> > > > > `g_object_add_weak_pointer' in these places in future versions.
> > > >
> > > > I definitely agree we should avoid dangling pointers as much as
> > > > possible. However, I fear a bit that many people will turn to using
> > > > pointers when this is also applied to local variables.
> > >
> > > Why do you think people will switch to pointers? Do you have an example
> > > in mind where the change might cause issues?
> >
> > I don't see an immediate use case where this might fail. However, weak
> > local variables can be used to tweak unnecessary reference counting
> > overhead. Registering the pointers possibly invalidates this tweak. We
> > have to wait an see how this actually behaves in for example loops etc.
> > Judging from the implementation within GObject, weak references might
> > actually be slower as strong ones.
>
> You should not use weak for performance improvements with the new
> syntax, it's only meant to break reference cycles or to not keep an
> object alive for other reasons.
>
> The unowned modifier will still allow you to avoid any kind reference
> counting or tracking. There will just be no guarantees at all if you do
> that.
I am confused with weak and unowned. Saying if gtk_window_list_toplevels
returns a list of GtkWindows, should these be unowned or weak?
List<weak Widget> Gtk.Window.list_toplevels();
or
List<unowned Widget> Gtk.Widget.list_toplevels();
Because in devhelp it is written that the elements are not referenced:
Returns a list of all existing toplevel windows. The widgets in
the list are not individually referenced. If you want to iterate
through the list and perform actions involving callbacks that
might destroy the widgets, you must call g_list_foreach (result,
(GFunc)g_object_ref, NULL) first, and then unref all the widgets
afterwards.
perhaps weak will be useful only for member variables(they are on the
heap) after the invention of 'unowned', given the add_weak_pointer use
case?
- Yu
>
> > As a side note, we probably need to invent a similar functionality for
> > non-GObject classes *if* we want to avoid dangling pointers all
>
> Yes, either that or we should probably at least warn when using weak for
> types that do not support it.
>
> > together. Also, I'm not sure how to treat the low level vala pointers in
> > this case.
>
> If you use raw pointers, you are on your own, I don't think it makes any
> sense to try to make the code safer there. Better try to avoid
> situations where raw pointers are necessary.
>
> > Perhaps we can combine this with a compile option that is set by default
> > to enable runtime checks.
>
> I'm not sure whether that's such a good idea as semantics would change.
> If you expect the reference to be null after the object has been
> destroyed, the application wouldn't work anymore when disabling the
> runtime check. After all, you can use `unowned' or raw pointers in
> performance critical parts, if really necessary.
>
> Jürg
>
> _______________________________________________
> Vala-list mailing list
> Vala-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/vala-list
_______________________________________________
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
