[10645] in The GTK GIMP ToolKit mailing list archive

home help back first fref pref prev next nref lref last post

[gtk-list] Re: potential problems with malloc/free vs. C++ new/delete

daemon@ATHENA.MIT.EDU (Dave Reed)
Thu Dec 3 09:24:33 1998

Date: Thu, 3 Dec 1998 09:28:06 -0500
From: Dave Reed <dreed@capital.edu>
To: gtk-list@redhat.com
In-Reply-To: <36669C74.E132C5BF@avid.com> (message from Paul Miller on Thu, 03
	Dec 1998 09:13:08 -0500)
Resent-From: gtk-list@redhat.com
Reply-To: gtk-list@redhat.com


> >   gchar **text;
> >   text = new gchar*[8];
> >   for (i=0; i<8; i++) {
> >     text[i] = new char[100];
> >   }
> >         // set values of text[i]
> >   gtk_clist_insert(clist, location, text);
> 
> > Should I instead be using malloc and free (or the glib wrappers) for
> > any allocation for gtk even though my program has to use new and
> > delete for the C++ class alocations?
> 
> If there already isn't, there should be a gtk_alloc/gtk_free pair that
> you should use for any allocations that gtk will use, and for any
> deallocations of gtk-allocated memory you will do. This is similar to
> Xt's XtMalloc and XtFree, which merely wrap malloc/free. This way, there
> is no question as to which api to use.
> 
> In the time being, if gtk uses malloc/free then you should do so as well
> for gtk-related memory as above. It's best not to take chances!

Ok so, I should probably change those "new"s to "malloc" or the glib
wrapper version.

For some reason I was also thinking that I read a program should
either exclusively call new/delete or free/malloc, but clearly that
can't be true or any mixture of C/C++ code would not work.

Thanks,
Dave
dreed@capital.edu

-- 
To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null


home help back first fref pref prev next nref lref last post