Re: [Vala] Allow passing ref/out as a pointer.

[Tal Hadad <tal_hd hotmail com>]

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: jaap vdnberg net
To: tal_hd 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: lethalman88 gmail com
To: tal_hd hotmail com
CC: vala-list gnome org

2012/4/15 Tal Hadad <tal_hd 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