Boxed Types

[Daniel Elstner <daniel elstner gmx net>]

Hi,

we (the gtkmm team) are a bit confused about the concept of Boxed Types
in the GObject type system.  Although there is an abstract copy/free
interface, it is not clear whether we should actually use it in C++,
since C++ supports the concept of automatic objects allocated on stack
as well as C does.

So far, we encountered 3 different kinds of Boxed Types.  Please correct
me if I made any wrong assumptions:

1) Simple structs like GdkRectangle, which members are all public. 
These can be copied by simple assignments, thus don't need public
copy/free functions.  A valid rectangle can be obtained by allocating it
on stack and initializing all members to 0.  They only need to be Boxed
Types for use with properties or GValue.

2) Opaque or handle types like GdkCursor, that use reference counting. 
New GdkCursor objects can be created with gdk_cursor_new(), or are
returned by GDK/GTK+ functions.  These are dynamic-only types.

3) Mixed types like GtkTextIter.  Although all members are private, it
can be allocated on stack, and it's guaranteed to be copyable by simple
assignments.  A GtkTextIter on stack doesn't have a valid "empty" state,
neither is there a gtk_text_iter_new().   Although it's never used
dynamically by the C API, copy/free are public, intended for use by
language bindings.

Now, I've several questions:

Why are copy/free for GtkTextIter public, but not for GdkRectangle?

Is there a generic way to know whether a type can be copied by simple
assigments, or do we have to look at the docs/headers?  (Some kind of
flag retrievable via the g_type_* API would be useful.)

If a struct can be assigned, is it guaranteed that this won't change in
a future version?

Currently, no GTK+ functions return a dynamically allocated
GtkTextIter.  Is it safe to rely on this?

Thanks for your time,
--Daniel