I may not be understanding you correctly, but an interface is a gobject
mechanic. This is intended as a quick and simple mechanism for non-gobject
library bindings.
Free shouldn't actually be needed, since that's handled by the specified
unref_function, but something as simple as:
[Compact]
[CCode (lower_case_cprefix = "PyObject_",
ref_function = "Py_IncRef",
ref_function_void = true,
unref_function = "Py_DecRef",
new_function = "PyObject_Malloc")]
public class Object {
Like ref_function and unref_function, it's just a drop-in replacement for
the memory allocation function Vala would otherwise use which doesn't work
with some bindings as they use their own internal memory management.
On Thu, Jun 18, 2009 at 4:03 AM, Sam Liddicott <s...@liddicott.com> wrote:
> I've given this a lot of thought.
>
> Here's some ideas:
>
> A memory management interface which implements these. A class implements
> the interface with it's own specific management.
>
> This would be better done by late binding, the microsoft way, where the
> object supports IInterface so it can be queried for a complete memory
> management interface.
>
> As this isn't likely to be magically compatible with what we have now; I
> have another solution; based on a tree of memory allocation pools.
>
> Any allocation of memory (or super allocation) is registered with the
> memory pool library. It is then possible to call find_allocation(void* ptr)
> and be returned the management interface for that pointer.
>
> It may be easier if a library will mmap memory it allocates, it become a
> matter of checking which range of mmap'd memory the pointer lies between.
>
> Thus it will be easy to get the memory management interface associated with
> a pointer.
>
> Sam
>
_______________________________________________
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
