Re: Lacking of a ref-counted string.

[Jamie McCracken <jamie mccrack googlemail com>]

On Wed, 2008-08-20 at 21:07 -0400, Havoc Pennington wrote:
> Hi,
> 
> On Wed, Aug 20, 2008 at 8:47 PM, Yu Feng <rainwoodman gmail com> wrote:
> > First, it is very difficult to manage a string without a reference
> > count. The current vala implementation is to assume that strings are
> > immutable, and to copy the strings almost everywhere where increasing
> > the ref-count should be used. The copying mechanism produces workable
> > code, but doesn't work in a efficient way. This is where it hurts.
> >
> > Secondly, vala doesn't introduce any additional dependency other than
> > GLib, to implement it in VALA level, the only way is to embed it in the
> > compiler. A compiler with embeded code to do a ref-counted string
> > doesn't sound nice. This is why I think it should be done at GLib level.
> >
> 
> If we think of GLib features as either for C, or for language bindings
> in general, or for vala, this particular feature seems like it would
> be *only* for vala - refcounted strings would be pretty strange in
> plain C, and just overhead for other language bindings that already
> have native string types they have to convert gchar* to.
> 
> Putting only-useful-for-vala features in GLib would seem odd to me.
> Just one opinion, though.
> 
> Can't vala do the same optimizations a C programmer would do by hand
> in most cases - avoiding a copy for a const char* that is only stored
> temporarily in local scope, for example? For other cases, a plain C
> program would have the same inefficiencies as vala it seems like, and
> they are not fatal inefficiencies...
> 
> What about a libvala? I guess vala is supposed to have this property
> that it doesn't create dependencies in distributed tarballs, but that
> design goal has brought us autoconf and libtool in the past... not
> sure I'm sold on it.
> 
> Or then, embedding it in the compiler does not seem like a very big
> deal - it's just two operations ref and unref, both of which are
> trivial and can just be inlined...
> 
> Havoc

I think we are confusing issues here

Its GString and not char * which needs the ref counting

Other languages (C++ and Delphi) both use ref counting for their strings
and they are invaluable to C devs too who do multi-threaded stuff. This
is clearly not vala specific as a result (ever tried to free a string
correctly where its used in multiple threads?)

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

jamie