Just some musings... I suspect this has been discussed before, though I
couldn't find anything in a cursory glance through the search engine. (But
then I'm notoriously hopeless with search engines)
> > Next thing is, that GLib memory subsystem don't really free memory
> > on g_free(), but do this when program exits. Memory freed with
> > g_free() is still 'located' for program, which allocated it for
> > first time.
> Yes, that's true. Its only true for any memory created by using
> g_slice. g_free is the same as a free. Memory is then returned back
> to the system.
One thing I have a question about, is the allocation of strings.
If I want to combine a gchar* username, and a gint number, to form a new gchar*
identifier, and use that as the name of a widget... It ends up going something
like this:
gchar *uid = g_strdup_printf("%s-%i", username, number);
gtk_widget_set_name(GTK_WIDGET(widget), uid);
g_free(uid);
Here, we're allocating memory with g_malloc(), writing a value into it, then
allocating more memory with g_malloc, into which that value is then copied.
Finally, I need to free the original memory.
And quite often, when fetching a value from glib/gtk, it'll g_strdup() (or
similar) the value which it then returns, and which I have to g_free() when I'm
finished with it.
Surely this must have an impact on memory and time usage.
In C++, we have the likes of the STL Strings, which perform reference counting,
treating a string with more than one reference as immutable. The presence of a
length and allocated length probably makes them a little large, possible even
larger than the strings they're holding. But a simplified container which
contains the string internally, with a leading reference count, I'd say would
do wonders.
Fredderic
_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
