This is exactly what I meant when I post this thread. I use your advice and use pointers for binding, so it's alternative to must have arrays. Even though Luca binding(array_length_pos=-1) is great for modern language syntax, it is less powerful than the old C fashion way.
Tal Date: Sun, 15 Apr 2012 20:38:23 +0200 From: j...@vdnberg.net To: tal...@hotmail.com Subject: Re: [Vala] Allow passing ref/out as a pointer. On 04/15/2012 12:57 PM, Tal Hadad wrote: You're right! The problem is that I forgot to gl_begin () also in initialization(i.e. before game loop). Thanks all! Tal Date: Sun, 15 Apr 2012 12:48:58 +0200 Subject: Re: [Vala] Allow passing ref/out as a pointer. From: lethalma...@gmail.com To: tal...@hotmail.com CC: vala-list@gnome.org 2012/4/15 Tal Hadad <tal...@hotmail.com> Thanks, but this code doesn't work either: GLuint[2] a = {20000,50000}; glGenBuffers (2, &a[0]); stdout.printf ("Buffers: " + ((uint)a[0]).to_string () + ", "+ ((uint)a[1]).to_string () + "\n"); ... public extern void glGenBuffers (GLsizei n, GLuint * ids); Output(same): Buffers: 20000, 50000 Someone knows why? The generated C call is correct with glGenBuffers (a), with the vapi I mentioned earlier. Maybe it doesn't work because you are missing some GL context? Also, try with zeros instead of those numbers? I had problems with the use of arrays of structs, similar to those that one would use with Open GL, as well. Things were even quite different after the introduction of vala-0.14. The main observation I made is that vala is using intermediate variables when an array element is referenced. The compiler generated the following eror message at some point: 'ref and out method arguments can only be used with fields, parameters, local variables and array element access' I had considerable problems understanding the semantics of arrays of structs, that I did not want to copy around. Since I did not want my arrays elements being copied, I used pointers to the array elements, like var ai = &a [i]; where ai is a pointer-variable with the type of the structs used as array elements. When writing var bi = b [i], you get something quite different, bi is represented by an intermediate variable allocated on the stack, filled with &temp, where temp is a copy of the struct b [i]; somewhere on the stack. This latter bi-variable has semantics that are quite different from the pointer semantics of the ai-variable. It is possible to pass the bi variable as an argument, without copying the struct b [i], but the intermediate variable bi cannot be the return value of a function. You may be tempted to write &a [i]->fun (foo, bar) to assign foo and bar to fields of the struct, but this does not work. The problem is that vala creates since 0.14 as well an intermediate struct on the stack, that receives the modifications. The target struct that one expects to get modified is hence kept unchanged. Instead it is needed to have a static function fun, and to call this static function with &a[i] as additional first argument to get the desired effect. There are good reasons to copy structs from arrays, since it is problematic to resize an array, as long as there are pointers to elements of the array that are still significant. It is however also important to understand the implications of the copy operation. A struct element with an embedded array instance will copy the whole array when the struct is to be copied. This may be what one expects when a copy of a value is made, since the value will be copied in full detail, even if you thought that array instances might be excluded from the copy-rule. There are hence also good reasons to have pointers to array elements. The problem is however that the language behaves quite differently for similar syntactic constructs, like pointers to structs, struct references and class references. One solution could be to use compact class instances as a replacement of structs in arrays. The 'only' problem is that the sizeof a compact class instance is the size of a pointer, this is not the same as the size of the struct that implements the compact class. These compact class instances will live as long as the array in which they are embedded, so there is no need to do reference counting on individual instances. The idea would hence be to introduce say a 'compact_struct', that behaves in all aspects of allocation like a struct, but in all aspects of usage and access like a class that is accessed with a pointer. This may help to keep the semantics simple and clean, while extending the functionality to problems frequently handled in c with the existing vala-syntax. jaap
_______________________________________________ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list