Re: signals versus vfuncs
- From: "muppet" <scott asofyet org>
- To: gtk-devel-list gnome org
- Subject: Re: signals versus vfuncs
- Date: Fri, 9 Jan 2004 13:20:45 -0500 (EST)
Christof Petig said:
> muppet schrieb:
>> another point of contention: GtkTreeIters are designed to be used by
>> allocation on the stack, and as such, have no destructors. the boxed free
>> function is just g_free(). this means i have no hook on iter destruction,
>
> IIRC g_free is not used at all (on stack data silently exits scope and
> lifetime).
yes, for stack-allocated iters, that's true. for heap-allocated iters, those
allocated with gtk_tree_iter_new() or gtk_tree_iter_copy(), and
gtk_tree_iter_free() simply calls g_free(). iters passed through signal
marshallers go into GValues containing G_TYPE_BOXED and thus are subject to
gtk_tree_iter_copy() and gtk_tree_iter_free().
this means you can never have anything but plain pointers inside, which
requires a level of control of those pointers that is really tricky to achieve
with the perl internals, as perl likes to reuse scalars for efficiency.
>> is there any way at all to get notification when an iter is no longer in
>> use? perhaps there's something simple i'm missing...
>
> There is a way to get notification: Who but the perl program would ever
> create or delete nodes? You have ultimate control over the contents and
> lifetime of each and every node.
erg. i was afraid that was the answer. you see, the perl program has that
complete control, but the bindings have to figure out how to keep from leaking
references without limiting the possibilities for the downstream code. looks
like i have no choice but The Hard Way.
thanks for all the help, by the way.
--
muppet <scott at asofyet dot org>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]