Fw: [cffi-devel] New and delete pertaining C wrapper for C++ code

[Joeish W]

Thanks for your reply..I can't rewrite the C wrapper for the C++ function so  I wrote  a delete wrapper like the below because I was getting a warning when it didn't have the char* and I heard you could  also use char* explicitly to remove warning.  My defcfun is standard it accepts a :pointer and returns void....I use it in my programs wherever memory need to get deleted ...I'm pretty good at knowing where to put the memory freeing functions but I still am getting memory leaks that make me have to restart.The memory I'm trying to free is a Mat*, Mat is an OpenCV c++ class...any help is appreciated

void delete_ptr(void* ptr) {
    delete (char*)ptr;
}






On Saturday, March 22, 2014 2:31 PM, Daniel Herring <dherring at tentpost.com> wrote:
 
On Sat, 22 Mar 2014, Joeish W wrote:
>
>
>> I have a whole list of C wrappers for OpenCV C++ functions like the one below. And all of them return a "new".  I can't change them because they are becoming part of OpenCV and it would make my library perfect to have a consistently
>> updated skeleton to wrap around. My question is in this case how would one of you free these "new" memory allocators...When I run them in any kind of
 loop.  It just eats up my ram, I
 end up having to restart my pc. Should I make a
>> "delete" wrapper and use that.
>> I've tried using foreign-free but I still have the same issue of having to restart. Any help is appreciated.
>> 
>> Mat* cv_create_Mat() {
>>     return new Mat();
>> }
>
>
>Hi Joeish,
>
>Long story short, you need to follow new() with delete().
>
>C++ new() and delete() extend C's malloc() and free() in roughly the 
>following way.
>
>T * new(args) {
>   T *x=(T *)malloc(sizeof(T));
>   x->T(args); // constructor (aka ctor)
>   return x;
>}
>
>void delete(T *x) {
>  
 if(x) {
>     x->~T(); // destructor (aka dtor)
>     free(x);
>   }
>}
>
>Note that both the constructor and destructor are fairly arbitrary 
>functions, and it is common for them to do additional memory management.
>
>
>- Daniel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cffi-devel/attachments/20140322/bfaaa8f2/attachment.html>