Re: [Vala] Lacking of a ref-counted string.

[Yu Feng <rainwoodman gmail com>]

On Wed, 2008-08-20 at 22:43 +0200, Jürg Billeter wrote:
> On Wed, 2008-08-20 at 22:29 +0200, Ali Sabil wrote:
> > On Wed, Aug 20, 2008 at 9:10 PM, Yu Feng <rainwoodman gmail com>
> > wrote:
> >         Dear Devs,
> >         
> >         Is there any particular reason that GLib doesn't provide a
> >         ref-counted
> >         string and a ref-counted array type? Lacking them in GLib
> >         makes the VALA
> >         language a real pain.
> >         
> > I don't really see your point, strings in vala are immutable, so there
> > is no real point in having them shared across objects. 
>
> Well, it would certainly be nice to have reference counted strings to
> avoid endless strdups, however, I don't think it would help if glib
> introduced ref-counted strings now. The existing libraries can't and
> won't just switch to the new type, so we just have to deal with multiple
> string types.
The point is, if GLib has a ref-counted string, then it becomes
reasonable to support unmanaged non-ref-counted strings in VALA. Then it
becomes reasonable to provide routines do the manual memory management
for non-ref-counted strings. And we are out from the strdups.

Make a distinguish between String and string:
String: ref-counted, can be strongly referred or weakly referred,
managed by vala just as other classes. No special treatment and strdup
for no more.
string: non-ref-counted, can only be weakly referred, managed by the
programers with new and delete. It becomes the programmer's duty to copy
them when needed. (either by an explicitly string.dup method or a
special new operator)

For general programers, they only need String. For those who are gluing
with GLib and knows what they are doing, string can meet their
requirement.

The same principle also works for arrays.

> Also, as strings are immutable, there would be no practical difference
> in using strings in Vala, it'd really just be an optimization. As
> creating a single GObject is way more expensive than a string copy, I'd
> assume that string copies are usually not the biggest performance issue.

If strings are copied and freed frequently, won't the memory become
fragmented? See JohnMoser's talk at
http://live.gnome.org/MemoryReduction

I have a strong feeling that Vala's strdup's tend to make the UUxxxxxxU
pattern but haven't been able to prove it.


Yu
> Jürg