Re: Lacking of a ref-counted string.



On Thu, 2008-08-21 at 12:18 +0200, Mikkel Kamstrup Erlandsen wrote:
> 2008/8/21 Yu Feng <rainwoodman gmail com>:
> > On Wed, 2008-08-20 at 17:59 -0400, Havoc Pennington wrote:
> >> Hi,
> >>
> >> On Wed, Aug 20, 2008 at 3:10 PM, Yu Feng <rainwoodman gmail com> wrote:
> >> > 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 think you would have to explain more why this is an issue for vala,
> >> at least for me (maybe everyone else already knows)
> >
> > OK.
> >
> > Vala claims automatic memory management and a programming language on
> > top of GLib.
> >
> > 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.
> >
> > 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.
> 
> How about using a GStringChunk and apply some magic compile-time
> logic? Although I am not quite sure how it should be done - you are
> the wizards :-)
> 
> It could maybe also make more sense to add some more API to
> GStringChunk as it is quite limited as it stands.

Perhaps not since GStringChunk is not thread-safe and can't be globally
held. and adding one for each thread is insane.

> 
> Cheers,
> Mikkel



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