Re: .defs Issues From Java-Gnome
- From: Owen Taylor <otaylor redhat com>
- To: gtk-devel-list gnome org
- Subject: Re: .defs Issues From Java-Gnome
- Date: 02 Jan 2001 15:10:37 -0500
Tim Janik <timj gtk org> writes:
> On 14 Dec 2000, Havoc Pennington wrote:
> > For cheap value objects, including primitive C types such as "int" and
> > higher-level types such as GtkTextIter and GdkRectangle, sometimes the
> > object is an out or inout parameter; in those cases you have to pass
> > the object in to a method by reference, so you can't just copy these
> > things always.
> basically you're right. except that, the signal system in its current
> form (and the type system with all its readily-boxed-magic ;) don't
> know about passing value types by reference, which gets us all that
> demand-copying mess.
> we had some proposals for using additional GtkType flags to indicate
> value-type references, but basically they were put down because they
> didn't scale too well. i'm still somewhat uncertain as to what the best
> approach here is... ;(
The problem wasn't scaling but the fact that problem here can't
be solved on a type-by-type basis, it needs to be solved on
a use-by-use basis.
The only real solution here is:
g_value_set_boxed_nocopy (&value, boxed_type);
Handling of freeing the value can be done in two ways:
- Convention. If you called g_value_set_*_nocopy(), then you
should not call g_value_unset().
- Keep a flag. You can do the same trick as you did for
g_value_set_static_string() by storing this flag in data.
[ Repeat once again the comment about data being useless ]
Since you have previously expressed strong opposition to the
first option, it seems like the second option is the way
we should handle this.
g_value_set_static_string() needs to be renamed to
g_value_set_string_nocopy() to go along with this, since the concept
of "not copying" is considerably more generic than "static".
] [Thread Prev