Hi, On Wed, Aug 20, 2008 at 9:31 PM, Jamie McCracken <[EMAIL PROTECTED]> wrote: > Its GString and not char * which needs the ref counting
That seems fine. But GString is just a temporary buffer (it's like StringBuffer/Builder in Java, not like String in Java). It's virtually never passed around in APIs. The way g_string_free() works is incompatible with refcounting, though. Perhaps g_string_free() could assert that the refcount is 1. The g_string_free() API does illustrate what GString is intended for (a way to create a char*) > At the moment there is an inconsistent split between glib structures > like GHashTable which use ref counting and the others (GList, GString et > all) which dont. I do hope GLib 3 will fix this I think the philosophy is that refcounting (and thread locking) work best on a bit less granular a level, such as an object or struct. In my experience that is pretty safe to say, when coding in C. And languages (other than vala) have their own lists, strings, refcounting/GC schemes, and thread safety schemes. When GTK or GLib needs to do strings in a threadsafe way it normally just copies them. The other option of course is to make them refcounted and immutable, but GString (like StringBuffer/Builder) is the opposite of immutable. We could have a refcounted GString that is immutable, but that has pretty much nothing to do with current GString. Havoc _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
