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

[Yu Feng <rainwoodman gmail com>]

On Wed, 2008-08-20 at 22:39 +0100, Sam Liddicott wrote:
> One of the uses of char* is a string buffer, not immutable but not neccesarily weak either.
> 
Oh yes when I used the term 'string' I was talking about the reference
to string object.

> Vala doesn't make it simple to transfer ownership but keep a weak reference when passing a shared string.
> 
I don't quite understand.

> You can do it with an extra variable because quite naturally it is the variable that is weak, not the string...
> 
Sure. being a block of memory, the object itself neither weak nor strong
applies to an object. When we declare a variable in VALA, it is always a
reference. The object (ie the memory block) is created with the 'new'
operator.

With a strong reference, when the variable leaves its region, the
reference count of the object decreases and we achieve the automatic
memory management with ease; when a weak reference leaves its region,
the reference count is untouched.

> I think this complicates the transmution from String to string because it will depend on if a shared buffer was intended.
Using the string as a buffer is a case where a weak reference is needed.
It is the idea of managing non-ref-counted objects that complicates
everything.

> 
> Sam
> 
> -----Original Message-----
> From: Yu Feng <rainwoodman gmail com>
> Sent: 20 August 2008 22:09
> To: JürgBilleter <j bitron ch>
> Cc: Vala Mailing list <vala-list gnome org>
> Subject: Re: [Vala] Lacking of a ref-counted string.
> 
> 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
> > 
> > 
> 
> 
> _______________________________________________
> Vala-list mailing list
> Vala-list gnome org
> http://mail.gnome.org/mailman/listinfo/vala-list
>