Re: Why is "gc" tag method restricted to userdata?

[Reuben Thomas <Reuben.Thomas@...>]

> Fortunately this is the correct order, provided that you also say in
> the manual that lua_newtag() dishes out the tags in increasing order
> :)  However, the tag may already be used for something else, such as
> to indicate the C++ type of the userdata, in which case this is not a
> solution.

I wonder whether another solution is effectively to manage the GC yourself
in C++: every time you get a call to your GC fallback for a userdata
object, check whether it points to anything else that might need to be
garbage collected, and if so, queue the current object, rather than
immediately deleting it.

The only difference between this and the approach you'd take if you were
able to write fallbacks for table GC is that you have to manage state
across a number of calls, rather than doing it all in one lump (and
there's still the same problem potentially in the latter case: what
happens if a C++ userdata object in one table points to one that is used,
directly or perhaps indirectly, in another table?)

In general, you might have C++ objects in lots of tables, all of which
need to be freed in a particular sequence. So having a GC fallback for
tables only pushes the problem back a level, while making the API more
complex.

I grant that in your particular case, you may only have intra-table
dependencies, so for you, having a table GC fallback might be enough for a
simple solution. For others, just having userdata GC fallbacks is
enough. From the API design point of view, it seems best to keep it
simple.

-- 
http://sc3d.org/rrt/ | violence, n.  bravery for cowards