Re: tolua++ porting to 5.2

[William Ahern <william@...>]

On Tue, Jan 15, 2013 at 02:49:59PM +1100, Ross Bencina wrote:
> On 15/01/2013 11:33 AM, Jay Carlson wrote:
> >The fix for this would involve C-side deallocation turning Lua-side
> >references into tombstones, and I don't see an obvious way to
> >implement tombstones other than something that works out to be Tim's
> >serial numbers.
> 
> How about this for an eager alternative to the counting thing. I haven't 
> tried this. I don't think it's better (aside from avoiding the page 
> fault issue). I'm mentioning it as a model to think about options:
> 
> Any pointer to a C object in Lua could be represented by a struct:
> 
> struct TrackedLuaCPointerNode{
> 	TrackedLuaCPointer *next;
> 	void *cobject; // pointer to c object
> }
> 
> In C/C++ wrap/intercept the allocator so that there is a 
> TrackedLuaCPointerNode* stored just before the allocated C/C++ memory 
> region. This pointer is used as the head of a linked list of 
> TrackedLuaCPointerNodes that point to the region.

Yeah, but these schemes are usually a bad idea. Scratch that--they're
_always_ bad. It's far saner to just suck it up and add reference counting
semantics to those C or C++ objects bound as userdata in Lua.

That should be even easier in C++ than in C, although I'm not too familiar
with C++. I would imagine that something like shared_ptr would be a sane
prerequisite for an automatic C++ bindings generator.

In any event, the process of adding reference counting--examining and
analyzing object lifetimes--would undoubtedly improve the quality of the
codebase generally.

But, sadly, too few people have the fortitude to turn down such
opportunities to subvert the system allocator. (Not implying you're one of
those people. ;)