Re: [Vala] Various tests with the new contract support, but also with non-GLib.Object classes
- From: Philip Van Hoof <spam pvanhoof be>
- To: vala-list gnome org
- Subject: Re: [Vala] Various tests with the new contract support, but also with non-GLib.Object classes
- Date: Thu, 24 Apr 2008 01:31:06 +0200
I also wonder where the memory for " t = test_new ();" is protected for
the use in app_thread_func as "app_y". As far as I can see is "app_test"
assigning app_y to t (and if app_y was not NULL, freeing app_y first).
That's probably as a result of y = #t; where I demand an ownership
transfer.
But the last line of app_test is going to free my t, right? Leaving me
with a broken app_y, which I will be using in app_thread_func later.
Bit confused ...
Will this only ever work with GLib.Object inherited types (ones that
have reference counting)?
Why not replacing "test_free" with a "test_unref" and adding a member
called ref_count to "struct _Test" and do it right in stead? When I make
myself a class in vala, I kinda 'okay' valac to do such things for me.
On Thu, 2008-04-24 at 01:22 +0200, Philip Van Hoof wrote:
I was just testing various things in vala, and noticed this:
pvanhoof schtrumpf:~$ ./test
** Message: test.vala:31: 100
** Message: test.vala:21: 99
pvanhoof schtrumpf:~$
I attached the test.vala file, since in class Test x will be initialized
to 100, and foo returns bar + x, those values are not right afaik.
ps. I peeked at the .c file, and self->x is never set to 100.
Also note that the ensures is never checked in the generated .c file
[esc]:/x =
"E486: Pattern not found: x ="
--
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://pvanhoof.be/blog
http://codeminded.be
--
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://pvanhoof.be/blog
http://codeminded.be
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]