> Hi all, especially Nicolas, > > i've updated the "cptr" library i use as a utility library for the -gl etc > bindings to -hopefully- be memory-safe. Now, the size of allocated memory > (specifically, the number of elements of the specific type) are stored in a > structure alongside the pointer itself. Access is checked with that and > results in exceptions if out of range. The allocated pointers will be > garbage-collected.
Please be careful with the GC of the pointer. It means that you must ensure that the pointer associated with the Neko value is not used anymore by any other data structure in your program :) Keeping everything referenced correctly and dealing with the GC is the most difficult part of the wrapper stuff. Once completely understood, it's quite easy to implement. > i have also added a few tests using haxe's brand-new unittest framework, > including one for memory leaks which will only work on linux (as it uses > /proc to find the memory usage of the current process). the tests will be > enabled if you compile with "-D test" and use CPtr as main class. > furthermore, the little library includes some eclectic utility functions that > will at some point move out to a different utility library. > > there is still open issues with NULL pointers, as handling these might > sometimes be a valid thing to do, and casting between pointer types. i have > ideas how to handle these situations, but currently i have no real use for > them, so they're just delayed. Why ? a NULL pointer is simply a pointer with size 0 no ? :) > i'd be happy if i can get some eyeballs on this; handling pointers in an > efficient and memory-safe manner is a pretty fundamental thing for my further > work on neko bindings. I'm checking your code and see that you're defining several kind of abstracts - one per pointer type. Does it makes really sense to have such an "high level" definition ? For instance you could just treat a pointer as a memory block where you can store several kind of RAW data. So for instance you could rewrite all cptr by not using a single abstract type and allow any kind of data to be stored inside. In fact, in there was no cptr_wrap method and if you could completely control the allocated memory, you could use plain neko strings to store this binary data. As for "util_msec" you can use [EMAIL PROTECTED] that will work the same all all platforms. Nicolas -- Neko : One VM to run them all (http://nekovm.org)
