[gambit-list] passing an f64vector
Marc Feeley
feeley at iro.umontreal.ca
Sun Mar 22 21:00:48 EDT 2009
On 22-Mar-09, at 1:21 PM, Eduardo Cavazos wrote:
> Hello,
>
> The type of the second parameter of gl function glGetDoublev is
> GLdouble*. So, I'd like to be able to pass an f64vector as that
> argument.
>
> The declaration of glGetDoublev is:
>
> void glGetDoublev( GLenum pname, GLdouble *params )
>
> So something along these lines I guess:
>
> (define glGetDoublev
> (c-lambda (GLenum scheme-object)
> void
> " glGetDoublev ( ___arg1 , UNPACKTHEVEC( ___arg2 ) ) ; "))
>
> Except with the proper unpacking of ___arg2. Any suggestions as to
> what
> macro to use there? I'm looking through gambit.h...
There is no builtin Scheme to C converter for homogeneous vectors
(u8vector, f64vector, ...). A converter for these types is
conceivable but a couple of issues makes it non-trivial:
1) A Scheme vector has a length, and often the length of the vector
may vary from one call to another (i.e. the length is a dynamic
property). How is the length of the vector passed to C? When a C
array is passed to Scheme, how does the converter determine how long
the array is?
2) To avoid GC problems (and in keeping with the other Scheme to C
converters) a copy of the vector would have to be made in a C array.
Unfortunately, for some functionality, the extra cost of doing the
copy may cancel the benefit of performing the computation in C.
3) Sometimes the vector is supposed to be mutated by the C function,
and the result of the mutations must be available to the Scheme code.
If the vector is copied the C function's mutations aren't preserved.
I have given some thought about various solutions to these problems,
but nothing definite yet.
In the meantime you can use the ___BODY(vect) macro in your code, it
returns a pointer to the first element of the vector:
(define glGetDoublev
(c-lambda (GLenum scheme-object)
void
" glGetDoublev ( ___arg1 ,
___CAST(___F64*,___BODY(___arg2)) ); "))
But beware... this assumes that the GC doesn't get invoked during the
call glGetDoublev (because a GC might move the vector). Even if the
GC isn't called explicitly, it is conceivable a GC could be invoked
asynchronously in a (real) multithreaded implementation of Gambit
(impossible in the current runtime system, but who knows... maybe a
multithreaded GC will be added in the future).
Marc
More information about the Gambit-list
mailing list