AW: tolua, classes and memory management

["Dirk Ringe" <dirk.ringe@...>]

You are right, the #define is not the correct solution, but for using the
correct heap the workaround worked out ok.

For a fool-proof implementation a tolua generated "destructor" should work
best. A forced base class would be a opt-out for tolua itself in our current
project.

Is there any ETA of a lua-4.0 compliant tolua? We are currently forced to
use lua 3.2 since tolua only supports lua 3.2. But for our current project
we need multi-state, so a switch to lua 4.0 is a requirement during project
progress.

Dirk

-----Ursprungliche Nachricht-----
Von: lua-l@tecgraf.puc-rio.br [mailto:lua-l@tecgraf.puc-rio.br]Im
Auftrag von Waldemar Celes
Gesendet: Donnerstag, 13. Juli 2000 15:19
An: Multiple recipients of list
Betreff: Re: tolua, classes and memory management


> 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