Re: tolua, classes and memory management

[rw20@...]

This is a problem I've worked around in toLua for about a year now.  I've 
done it my introducing a common base class and modifying the toLua 
deletion point to cast to that base class before calling delete.

That however is not a good general solution since adding a base class is 
not generally possible in C++ (it only works well when you have all the 
source and can tollerate setting up that hierarchy).

The only good way to do it is to have the toLua generated garbage
collection tag do the right thing: 
delete (ClassName *)luaObj;

toLua also must honor the copy constructor when duplicating an object 
(rather than doing a bitwise copy) --- seems like this issue was fixed; 
right?

Russ

On Thu, 13 Jul 2000, Waldemar Celes wrote:

> > Hi,
> >
> > I just got into an problem with tolua 3.2.2, which broke my code completely.
> > I discovered that tolua allocates memory for userdata types in c++
> > environments via the new function. But the memory is freed with the function
> > free (in toluaI_tm_undoclone) and not the function delete. There is even a
> > comment on that line that looks like the author knew what he did
> > ("free(clone); /* no destructor: use raw free */").
> 
> Yes, I am aware of that, and I thought it would work correctly for
> single inheritance (possibly with memory leak for complex objects).
> Sorry for not pointing it out in the docs.
> 
> The correct approach however is not a matter of just including #define
> __cplusplus.
> The code receives a pointer to void and you can not call delete for it.
> 
> I see two approaches to overcome the problem:
> 1) tolua could require that all objects returned by value to Lua inherits from a
> base class ToLuaBase,
> which would define a virtual destructor.
> 
> 2) tolua would generate, automatically, a "destructor_function" for each type
> returned by value to Lua.
> 
> As tolua tries not to impose conditions to the code being mapped, the second
> solution seems to be a better choice.
> I think that would work nice, isn't it? Any ohter ideas?
> 
> -- waldemar
> 
> 
>