Re: tolua++ porting to 5.2

[Hadriel Kaplan <HKaplan@...>]

We didn't pick tolua++ for a whole bunch of reasons, but the one indicated in your referenced message wasn't one of them - because every binding we investigated had that problem or something like it. (not that we researched every binding in existence, though)  

If I understand you right, the problem you're pointing out is that the Lua programmer incorrectly kept an object around in Lua, that C/C++ code deleted, that the Lua program tried to use later; and that instead of causing an immediate crash or error, it didn't because C/C++ had coincidentally created another object at the same address.  Right? (or maybe I misunderstand the problem you're reporting?)

Is there a binding that solves that problem?  How did it solve it?

We use Lunar[*], and had considered making all of our pushed C++ objects derive from a common base that had a member variable for a 'serial number': a number which is unique for every C++ object for all time.[**]  The pushed object in Lua would have a copy of this serial number, and would be checked against the C++ object's serial number on every method call.

-hadriel
[*]We modified Lunar a bit, but we've been very happy with it.
[**]well... for hundreds of years anyway; even a 64-bit integer incremented on every object construction won't roll over for a very very long time.


On Jan 14, 2013, at 1:30 PM, Tim Mensch <tim-lua-l@bitgems.com> wrote:

> On 1/14/2013 3:25 AM, Joop Boonen wrote:
>> I wonder if tolua++ could be a part of lua?
>> It's not supported any more and it's still quite widely used.
> 
> I can't recommend tolua++ to anyone; the core architecture they use for binding objects is profoundly broken, as I detailed in a previous message [1]. Looking through the code, I would recommend using a different project rather than trying to maintain it; it is really ugly code. I remember feeling surprised it worked at all after reading it.
> 
> Tim
> 
> [1] http://lua-users.org/lists/lua-l/2012-12/msg00601.html
>