[Vala] memory management with structs
Hi all: How is the memory management in vala when using structs instead of classes? I presume they are not ref-counted... The real questions are: * is it possible to use structs as elements in a Gee list without running into memory management problems? * How to avoid them, in case there are such problems? Or so Imust use true classes? * Can I use instead compact classes inside Gee lists adding them the memory management decorator? * In case the last answer is true, how are presented the compact classes outside Vala? (for programs using gobject-introspection). Is it possible to work with them from C? Thanks. -- Nos leemos RASTER(Linux user #228804) ras...@rastersoft.com http://www.rastersoft.com ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] memory management with structs
On Sat, May 18, 2013 at 11:41 AM, rastersoft ras...@rastersoft.com wrote: Hi all: How is the memory management in vala when using structs instead of classes? I presume they are not ref-counted... They aren't ref counted. Structs are value types, they are always either shallow copied or deep copied (depends on ownership). Beware the only difference is with nullable structs. Unfortunately the semantics there is a little different (it's a bug). Nullable structs are allocated on the heap and are not copied. The real questions are: * is it possible to use structs as elements in a Gee list without running into memory management problems? Yes, should be possible, int, double, etc. are vala structs. * How to avoid them, in case there are such problems? Or so Imust use true classes? You can use classes that don't inherit from GObject, which are lighter. * Can I use instead compact classes inside Gee lists adding them the memory management decorator? Compact classes are used for bindings, they aren't well supported when writing new vala code. * In case the last answer is true, how are presented the compact classes outside Vala? (for programs using gobject-introspection). Is it possible to work with them from C? As above, they're especially suited for bindings. Compact classes are usually non-ref counted. If it's not a struct and it's not a GTypeInstance, it's probably a compact class. -- www.debian.org - The Universal Operating System ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] memory management with structs (OT a bit)
On 18/05/2013 12:15, Luca Bruno wrote: You can use classes that don't inherit from GObject, which are lighter. Are such classes the [Compact] classes, or is any class that does not specify a parent class automatically a light class? \d ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] memory management with structs (OT a bit)
2013/5/18 Donn donn.in...@gmail.com On 18/05/2013 12:15, Luca Bruno wrote: You can use classes that don't inherit from GObject, which are lighter. Are such classes the [Compact] classes, or is any class that does not specify a parent class automatically a light class? Hi, no, compact classes are even simpler than non-Gobject classes. The latter still have reference count and can be extended, whereas compact classes are mostly classified structs without ref count which also cannot be extended in subclasses. ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] memory management with structs (OT a bit)
On 18/05/2013 13:40, Jonas Kulla wrote: no, compact classes are even simpler than non-Gobject classes. The latter still have reference count and can be extended, whereas compact classes are mostly classified structs without ref count which also cannot be extended in subclasses. Okay, but did that answer the question? I'm not sure. It was: You can use classes that don't inherit from GObject, which are lighter. Are such classes the: A) [Compact] classes or B) is any class that does not specify a parent class automatically a light class? i.e. How do you create a class that does *not* inherit from GObject? \d ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Vala and Cairo 1.12
2013/5/15 Donn donn.in...@gmail.com
Are there a lot of new functions in 1.12 that you need? If not,
you could just inline the function signatures in your vala code
until someone updates the official vapi.
It seems Evan Nemerson is on the case - yay! - but I'd like to know a
little more about this inline thing. Do you have an example so I can get
the picture? (I'm a Pythoner who tripped over Vala and I'm still rubbing my
chin.)
It's basically the same as declaring foreign functions in C.
Let's say you want to use the function 'int cairo_do_foo()' from Vala,
you would write something like:
namespace Cairo {
[CCode (cname=cairo_do_foo)]
extern int do_foo();
}
The 'CCode' part is a directive to valac for how it should
output the C code. We tell it the actual C function name
to use.
Jonas
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
