 |
lua-l archive |
|
|
||
|
> When you say:
>
> These strings are only "active" in the Lua function called from
> C++ side, and are GC'd as the script returns. Such strings have a
> very low lifetime, and do not need to be otherwise "managed" by
> Lua.
>
> I understand what you mean by the lifetime of the strings being very
> low, but you say they are GC'ed as the script returns. Do
> you mean that
> you explicitly force a garbage collection when the script
> returns or do
> you mean that you expect Lua to GC the strings when the script returns
> (which it will not, it won't GC the strings until it decides
> to do a GC,
> re pushing the string until then won't allocate any more memory)?
I meant the latter, sorry. The GC hit is delayed, but is still
there. It's not that bad in my case though, since a fair amount
of GC happens when I force them while loading a new map.
> If you measured the overheads associated with strings to be too large
> for your application then maybe numbers are the way to go.
> You can still
> use symbols to make it look nice in the source code, by doing
> #define MegaOption 7
> on the C++ side
> and
> MegaOption = 7
> on the lua side
I already do kind of this, but by only doing a file full of headers
that is #include'd by both C++ and Lua sources (Lua scripts get
cpp parsed before getting luac parsed), allowing for only one
definition of constants for the whole project.
Strings are required in some cases however, for examples when
interacting with a character (mainly talking) as you can't have a
define (well, you *could*) for every possibly word a given character
understands. And it's a bit cumbersome when the C++ side doesn't
know about a given string (eg it gets one from Lua, and passes it
back without assigning it semantics at any time). These cases are
usually not in the time critical code, however (in my case at
least).
--
Vincent Penquerc'h