[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



-------- 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]