Subject:
Re: [ruby-ffi] wiki update on pointers
From:
Jeremy Voorhis
Date:
5/11/10 1:03 PM
To:
ruby-ffi@googlegroups.com

Good point. I've created a handful of bindings using FFI, and in every case, either the library allocated and owned its memory, or Ruby did. The one exception to this is a current project which uses a custom pool allocator that has a similar api to your LibC example.

Best,

Jeremy

On Tue, May 11, 2010 at 10:34 AM, Chuck Remes <cremes.devlist@mac.com> wrote:
On May 11, 2010, at 12:01 PM, Jeremy Voorhis wrote:

It looks correct to me, except in my experience, MemoryPointer makes it unnecessary to wrap malloc(). For example, instead of,
  LibC.malloc(baz.first.size * baz.size)
I would write,
MemoryPointer.new(baz.first.size * baz.size).

The block form of MemoryPointer is also useful for automatically freeing the pointer when finished.

MemoryPointer.new(baz.first.size * baz.size) do |p|
p.write_array_of_int(baz)
C.DoSomethingWithArrayOfInt(p)
end

Jeremy,

I'll add a note about MemoryPointer's block form. Looks cool.

BTW, you can't use MemoryPointer for the example I gave on the wiki. As soon as the MemoryPointer goes out of scope, it is garbage collected and the memory is freed. That isn't so useful when the 3rd party lib is supposed to own and manage the memory lifecycle going forward.

But for other cases where the ruby code controls the memory lifecycle, MemoryPointer is a good choice.

cr