Re: Lacking of a ref-counted string.
- From: Yu Feng <rainwoodman gmail com>
- To: Ali Sabil <ali sabil gmail com>
- Cc: gtk-devel-list <gtk-devel-list gnome org>, Havoc Pennington <hp pobox com>
- Subject: Re: Lacking of a ref-counted string.
- Date: Thu, 21 Aug 2008 08:36:41 -0400
On Thu, 2008-08-21 at 07:57 +0200, Ali Sabil wrote:
> First, it is very difficult to manage a string without a
> count. The current vala implementation is to assume that
> strings are
> immutable, and to copy the strings almost everywhere where
> the ref-count should be used. The copying mechanism produces
> code, but doesn't work in a efficient way. This is where it
> I am not quite sure, to me you seem to mix up copy on write string and
> shared buffers, copy on write strings are just an optimization, and
> they don't need to be in GLib. Concerning shared buffers, string are
> *not* used in vala for shared buffers, simply because a string in vala
> is a utf-8 encoded *immutablle* byte sequences. a byte buffer is
> represented using uchar. Right now vala supports is pretty young
> concerning array supports, they are hard to manage in the first place
> because of the C quirks (null terminated arrays, vs arrays with an
> extra parameter to specify the length).
> To keep it simple, why don't you just write a ByteBuffer class
> inheriting from GObject ?
I don't know see any reasons.
> 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
> doesn't sound nice. This is why I think it should be done at
> GLib level.
] [Thread Prev