Re: Lacking of a ref-counted string.



Hi,

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
GString.

Havoc


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]