Re: [Vala] Lacking of a ref-counted string.
- From: Sam Liddicott <sam liddicott com>
- To: Yu Feng <rainwoodman gmail com>, JürgBilleter <j bitron ch>
- Cc: Vala Mailing list <vala-list gnome org>
- Subject: Re: [Vala] Lacking of a ref-counted string.
- Date: Wed, 20 Aug 2008 22:39:52 +0100
One of the uses of char* is a string buffer, not immutable but not neccesarily weak either.
Vala doesn't make it simple to transfer ownership but keep a weak reference when passing a shared string.
You can do it with an extra variable because quite naturally it is the variable that is weak, not the
string...
I think this complicates the transmution from String to string because it will depend on if a shared buffer
was intended.
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]