GNOME.org
 

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

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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]