Re: Lacking of a ref-counted string.
- From: "Havoc Pennington" <hp pobox com>
- To: jamie mccrack gmail com
- Cc: gtk-devel-list <gtk-devel-list gnome org>
- Subject: Re: Lacking of a ref-counted string.
- Date: Wed, 20 Aug 2008 22:44:44 -0400
On Wed, Aug 20, 2008 at 9:31 PM, Jamie McCracken
<jamie mccrack googlemail com> 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
] [Thread Prev