Re: why no gtk_tree_iter_new()?

[Havoc Pennington <hp redhat com>]

murrayc t-online de (Murray Cumming) writes:
> On Thu, 2001-11-01 at 15:46, Owen Taylor wrote:
> > 
> > murrayc t-online de (Murray Cumming) writes:
> > 
> > > I notice that functions such as gtk_tree_store_new() take pointers to
> > > allocated, but unset, GtkTreeIters, so in gtk-demo/main.c you have to do
> > > this:
> > > 
> > > GtkTreeIter iter;
> > > ...
> > > gtk_tree_store_append (GTK_TREE_STORE (model), &iter, NULL);
> > > 
> > > 
> > > Isn't there a risk that someone could end up calling
> > > gtk_tree_iter_free() on this. And if there is a gtk_tree_iter(),
> > > shouldn't there be a matching gtk_tree_iter_new(), which could also zero
> > > the struct memory to avoid undefined behaviour.
> > > 
> > > This wouldn't break the API, but would add a function to it. May I?
> > 
> > Same arguments apply here as for gtk_text_iter_new()
> 
> Was that "Yes, and we might need gtk_text_iter_new() too", or "No, we've
> already explained this for gtk_text_iter_new()".

There was a bug report for gtk_text_iter_new() recently.

Both GtkTreeIter and GtkTextIter area guaranteed to be allocatable on
the stack with no initialization. You can also allocate them in an
array like g_new (GtkTextIter, 3) or a single one g_new (GtkTextIter,
1) or even with "new GtkTextIter" in C++ was long as you don't call 
gtk_text_iter_free() yourself. i.e. these are just raw memory blocks.

GTK is never going to call gtk_text_iter_free() on a user-provided
GtkTextIter, except in the context of GtkTextIter as a boxed type.

Anyway, short answer, no need to zero the struct, don't worry about
how the GtkTextIter is allocated, it is just a memory block and GTK
applies no other interpretation.

Havoc