Re: boxed types and copies

[Havoc Pennington <hp redhat com>]

Tim Janik <timj gtk org> writes: 
> hm, i'm kinda two folded on that issue.
> 
> on the one hand, the easy thing to do is to restore gtk_signal_emit(),
> but then, your signals that use these boxed types are really only
> usable with gtk_signal_emit() (not g_signal_emit()).
> beyond that, code that deals with your boxed values will get things wrong,
> since you copy the structure while you actually want it passed by
> reference.
> i think owen has a similar thing with selection data or something...
> basically, boxed values that aren't usefully copyable, must be reference
> counted so they can be passed by reference.
> the reference counting doesn't need to be exposed, you can have static
> ref/unref and pass that in to g_boxed_type_register_static().
> 
> owen, what do you say? boxed types need to be either copy-able or
> reference counted, otherwise LBs or editors can't pass them around
> and store them away anyways. doing that static hack for gtk_signal_emit()
> just defers the problem and makes things work for just this moment in our
> limited testgtk universe.
> 

Pass by value or reference is a property of a function, not a property
of the type. That is why C and C++ have notation such as Foo* and Foo&
in addition to plain Foo.

Whether you _can_ copy or ref/unref a value is the property of the
value's type. But whether you _do_ copy/ref when passing to a function
is a property of the function.

So there is no way to get a logical "answer" for boxed types. They
_can_ be copied because they are boxed, but GBoxed should not say
anything about whether they _are_ copied in any particular situation.

Whether they are copied should be a property of either the GValue or
the signal.

Havoc