Re: [Vala] error on property;

[Yu Feng <rainwoodman gmail com>]

On Wed, 2008-08-20 at 18:54 +0100, Sam Liddicott wrote:
> Yu Feng wrote: 
> > Hi Alex,
> > 
> > Fortunately I was dealing with the same problem too.
> > The key is for a property, you almost always want a weak string, and
> > manage the string in the object. In other words, this code will be fine:
> > 
> > public class Info.PersonInfo {
> >   private string fio_;
> >   public weak string fio {
> >     get {
> >        fio_ = get_fio();
> >        return fio_;
> >   
> I don't think that is safe.

I hope vala will strdup the returned value when I do a
string foo = personinfo.fio.

I suppose vala will always strdup when deferring a weak to a strong ref.

> You are returning a weak string, but the owner will free it before the
> return actually happens.
> 
> I posted an example but it had some typos, I post a correct version
> here:
> 
> private string _fio;
> public weak string get_fio() {
>   if (_fio == null) {
>     _fio = "%s %C. %C".printf(l_name,f_name.get_char(),m_name.get_char());
>   }
>   return _fio;
> }
> 
> the object will keep _fio for it's lifetime after which we *hope* all
> weak references will have gone away.

> I agree that it is problematic; part of the issue seems to be that
> strings can't be reference counted and (apart from "weak") are also
> immutable. The strdup's in generated code drive me mad.

I've pointed out a 'solution' to them is to abandon any attempt of
managing the strings and leave the job to programmers in the other
post(the 'workaround' one)

> 
> I shall mention again that the talloc allocator not only ref-counts
> and has owners but has destructors AND is type-safe. Talloc for string
> management at least would make things much simpler. However it could
> complicate transferring ownership to glib libraries which would use
> the wrong free function.
In one word, talloc is not in GLib and doesn't fit into the GLib backend
of Vala. right? So far what I can understand is vala hasn't yet separate
the GLib backend from the core compiler.
> 
> I plan to do this anyway for samba.
> 
> The way out might be how Delphi handled conversion between String and
> char*, when the string is cast to char* it get's strdup'd to a single
> reference string (but ownership is not transferred, but could be).
> 
> It's not a complete solution, my thinking cap is still on.


Yu
> 
> Sam
> > }
> >   }
> >   public string get_fio(){
> >      // bluh bluh bluh
> >   }
> > }
> > 
> > I have to doubt that the memory management model for non-ref-counted
> > objects in VALA has some problem. I always go into trouble to use the
> > managed strings (string without weak), ending up with either compilation
> > failure or garbage C code that do a lot of useless strdup.
> > 
> > Yu
> > On Wed, 2008-08-20 at 19:46 +0400, Alexey Lubimov wrote:
> >   
> > > public class Info.PersonInfo {
> > >   public string f_name;
> > >   public string m_name;
> > >   public string l_name;
> > >   public string fio  {get {return this.get_fio();}}
> > > 
> > >   public string get_fio() {
> > >     return "%s %C. %C".printf(l_name,f_name.get_char(),m_name.get_char());
> > >   }
> > > }
> > > 
> > > 
> > > 
> > > PersonInfo.vala:12.7-12.28: error: Return value transfers ownership but 
> > > method return type hasn't been declared to transfer ownership
> > > 
> > > That's wrong?
> > > any tips?
> > > 
> > > 
> > > _______________________________________________
> > > Vala-list mailing list
> > > Vala-list gnome org
> > > http://mail.gnome.org/mailman/listinfo/vala-list
> > >     
> > 
> > _______________________________________________
> > Vala-list mailing list
> > Vala-list gnome org
> > http://mail.gnome.org/mailman/listinfo/vala-list
> >   
>