This works :)

38 (define (get-fullscreen-modes) 39 (define get-fullscreen-modes* 40 (c-lambda () sfml:Vector<VideoMode>* 41 "___result_voidstar = new std::vectorsf::VideoMode(sf::VideoMode::getFullscreenModes());")) 42 (define vector-video-mode-length 43 (c-lambda (sfml:Vector<VideoMode>*) size_t 44 "___result = ___arg1->size();")) 45 (define vector-video-mode-ref 46 (c-lambda (sfml:Vector<VideoMode>* size_t) sfml:VideoMode* 47 "___result_voidstar = new sf::VideoMode(___arg1->at(___arg2));")) 48 49 (let* ((modes (get-fullscreen-modes*)) 50 (size (vector-video-mode-length modes)) 51 (result (make-vector size))) 52 (let loop ((i 0)) 53 (cond 54 ((< i size) 55 (vector-set! result i (vector-video-mode-ref modes i)) 56 (loop (+ i 1))) 57 (else 58 result)))))

Is it also possible to accomplish the same directly from a c-lambda that returns a scheme-object?

Am 16.08.2013 09:54, schrieb Mikael:

Perhaps make a c-define-type for std::vector<VideoMode>* that you return the return value of .getFullscreenModes() as, and then make a -length and -ref procedure for this type.

Remember that for c-define-type :s that do not have a release procedure specified, there is *no* deallocation (such as free() etc.) invoked at their scheme-world GC.

2013/8/16 Chris Mueller <ruunsmail@gmail.com mailto:ruunsmail@gmail.com>

Hi,

i'm currently coding a gambit binding for sfml and could need some
adivces for a specific ffi problem from you.

Assume we have a class VideoMode with the following constructor:

class VideoMode {
public:
   VideoMode(int width, int height, int bbp);
   # ...
}


I have defined an interface to scheme with:

;; Release hook is ignored for this example
(c-define-type VideoMode* (pointer "VideoMode"))

;; Scheme's construction wrapper for VideoMode
(define video-mode
   (c-lambda (int int int) VideoMode* "___result_voidstar = new
VideoMode(___arg1, ___arg2, ___arg3);"))


Now assume a function that retrieves all supporting video-modes in
C++:

std::vector<VideoMode> getFullscreenModes();


I would like to write now a scheme-function (with c-lambda) that
iterators through all elements from this std::vector
and constructs/returns a scheme-vector with foreign-objects of type
(pointer "VideoMode").

How does the c-lambda code look like for this small issue? (Or how
would
you cope this problem alternatively?)


Chris





_______________________________________________
Gambit-list mailing list
Gambit-list@iro.umontreal.ca <mailto:Gambit-list@iro.umontreal.ca>
https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list

Am 16.08.2013 09:54, schrieb Mikael:

Remember that for c-define-type :s that do not have a release procedure specified, there is *no* deallocation (such as free() etc.) invoked at their scheme-world GC.

I've read in the documentation for the default release function (pointer ..) and (nonnull-pointer ...) types are not performing any deallocation like you mentioned.

I'm a little bit curious about (struct ..) type-definitions because due to the documentation it has probably a more useful default behaviour for releasing.

Can i assume if i allocate and use a (struct ...) type that the GC management system will handle this reference properly? (in contrast to pointers)

This would save me a lot of specific cleanup code for all predefined types if gambit's system is performing delete calls automatically for structs.

e.g.

(c-define-type std::string (struct "std::string")) (define string-new (c-lambda (nonnull-char-string) std::string "___result_voidstar = new std::string(___arg1);"))

Only for clarification for myself i don't create memory leaks.

Thanks, Chris

On 17.08.2013 22:59, Mikael wrote:

On struct it would make sense, it was indeed only pointered types I had on my mind. Allocate a billion, see for yourself and tell here?

I've checked this with the following example.

(define (alloc-string n) (let loop ((i 0)) (if (< i n) (let ((a (std::string "test"))) (loop (+ i 1))) (write "FIN")))))

When using (struct std::string ...) without a release function, memory grow's rapidly (checked this in htop) until it heap overflows.

With a given release function memory assumptions is constantly small.

Seems there is currently no difference in the deallocation behaviour between structs and pointer types.

Too bad :/

Chris

On 19.08.2013 06:13, Mikael wrote:

std::string requires delete to be used for proper deallocation and free() might just partially deallocate it, no? - what about trying with some more ordinary struct like tm ?

Could be, but i think this is not the case. The documentation mentioned if gambit is using g++ it should actually use 'delete (type*) internal-pointer'.

I've also checked this with a POD struct:

struct test { int A; int B }

It's no difference if * struct test is allocated with new * struct test is allocated with malloc

It's also leaking memory.

On 19.08.2013 12:16, Mikael wrote:

So in your past test with a pointered type, you did see the proper behavior. And here comes what applies to the current test:

In the case of the |struct|, |union| and |type| types, the default
function reclaims the copy on the C heap referenced by the internal
pointer (when using a C++ compiler this is done using ‘delete
(type*)internal-pointer’, which calls the destructor of type if it
is a class) and returns ‘___FIX(___NO_ERR)’.

Can you paste your full test code here?

Of course :)

;; struct definition (c-declare "struct test { int a; int b; };")

(c-define-type struct-test (struct "test"))

(define struct-test (c-lambda () struct-test "___result_voidstar = new test;"))

;; test code (load "test")

(define (alloc-struct n) (let loop ((i 0)) (if (< i n) (let ((a (struct-test))) (loop (+ i 1)) (write "FIN")))))

(alloc-struct 100000000000)

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. :)