Re: [Vala] error on property;

[Sam Liddicott <sam liddicott com>]

One way to safely work out the type of a string is to look at the address.

System-dependant it should be posible to tell if a pointer points to the stack, the brk heap or another mmap'd heap.

Perhaps there should be a multiple malloc handlers, each registering address ranges.

The global realloc (and/therefore free) can then dispatch to the right handler based on the address.

The system can thus support multiple alloc systems including those that refcount. It would be a good addition to glib too.

Juergbi?

Sam

---

From: Sam Liddicott <sam liddicott com>
Sent: 20 August 2008 18:54
To: Yu Feng <rainwoodman gmail com>
Cc: vala-list gnome org
Subject: Re: [Vala] error on property;

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

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.

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