[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
[Vala] [Fwd: Re: Lacking of a ref-counted string.]
- From: Yu Feng <rainwoodman gmail com>
- To: vala-list <vala-list gnome org>
- Subject: [Vala] [Fwd: Re: Lacking of a ref-counted string.]
- Date: Thu, 21 Aug 2008 08:38:58 -0400
-------- Forwarded Message --------
> From: Hubert Figuiere <hfiguiere teaser fr>
> To: Yu Feng <rainwoodman gmail com>
> Cc: gtk-devel-list <gtk-devel-list gnome org>
> Subject: Re: Lacking of a ref-counted string.
> Date: Wed, 20 Aug 2008 21:49:40 -0400
>
> On Wed, 2008-08-20 at 20:47 -0400, Yu Feng wrote:
> > First, it is very difficult to manage a string without a reference
> > count. The current vala implementation is to assume that strings are
> > immutable, and to copy the strings almost everywhere where increasing
> > the ref-count should be used. The copying mechanism produces workable
> > code, but doesn't work in a efficient way. This is where it hurts.
>
> Maybe having a copy-on-write implementation (in Vala) of the string type
> is what you want. That way, when you need mutability, you copy. That's
> the choice made by std::string and Glib::ustring (in glibmm that is
> incidentaly implemented using std::string) in C++ and transcribe pretty
> well the usage case.
>
>
> > 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 string
> > doesn't sound nice. This is why I think it should be done at GLib
> > level.
>
> That's a design choice, but it seem to be unavoidable to have a runtime
> library at one point. All the other language have one, more or less.
> Pascal, Java (libcj), Objective-C, Fortran, C++ and even C. I guess it
> is no exception for Vala.
>
>
libGee ?
>
> Hub
>
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]