On 20.08.2013 14:01, Mikael wrote:
Waait. I didn't check but I'm not so sure it's supposed to work like that - I wonder why you had access to ___result_voidstar there at all.
Yep, that's interesting. You can even use it in another procedures that expects a struct (it dereferences automatically the pointer).
In the documentation section 19.1 there are some interesting hints about that.
* internal pointer points to a copy of c-data type. * When an instance is converted from C to Scheme, a block of memory is allocated from C Heap and initialized with that instance. * After that a foreign-object is allocated from scheme-heap and initialized via copy-constructor from the c object in g++. * Deallocation of the copy on the C heap is under control of the release function attached to the foreign object.
i don't know whether managing the c-copy is in responsibility of the developer or the scheme compiler.
Please allocate such a test structure *locally on the stack* within your struct-test procedure, and then set ___result to it. I.e., by value and not by pointer passing. Then paste here again.
Here's the new procedure:
(define struct-test (c-lambda () struct-test "struct test x; ___result = x;"))
But if i run the test script with this function, i get a segmentation fault immediately.
There is also another option which comes in my mind:
(define struct-test (c-lambda () struct-test "struct test x; ___result_voidstar = &x;"))
This is e.g. running the allocation loop. But it will segfault when quiting the script with CTRL + X.
I've currently work around this by explicitly setting the release function with a simple c++ template.
typename <typename T> ___SCMOBJ release(void* ptr) { delete ((T*) ptr); return ___FIX(___NO_ERR); }
But it would be great, if we could clarify later the proper usage of structs in the ffi. I've gotten curious about that. :)