gpt4 book ai didi

c - 是否需要为本地范围处理复制表字符串?

转载 作者:太空宇宙 更新时间:2023-11-04 03:44:31 24 4
gpt4 key购买 nike

我处于从 Lua 接收字符串表的情况。我需要将字符串累积到一个数组中以调用内部 C 函数。字符串处理在函数范围内是局部的(即,函数返回后不保留对字符串的引用)。

现在,我做这样的事情:

int process_tokens(lua_State *lua)
{
char *tokens[TOKENS_MAX];
int ntokens = 0;

/* assume table at top */
while (ntokens < sizeof(tokens) / sizeof(*tokens)) {
lua_rawgeti(lua, -1, ntokens + 1);
if (lua_isnil(lua, -1))
break;
tokens[ntokens++] = luaL_checkstring(lua, -1);
lua_pop(lua, 1);
}

lua_pushnumber(lua, handle_tokens(tokens, ntokens));
return 1;
}

现在我的问题是:在这里复制字符串是否安全?我倾向于认为是的,因为包含它们的表在 process_tokens() 函数返回之前不能被 gc'ed(前提是它没有从堆栈中弹出),所以它包含的字符串不能太。另一方面,我还没有发现任何迹象表明在调用 luaL_checkstring() 时获得的指针实际指向何处(对象内部结构?某处的某种临时堆栈?)。

最佳答案

如果您不复制字符,我认为您是在自找麻烦。文档说,对于 lua_tolstring,“因为 Lua 有垃圾收集,所以不能保证 lua_tolstring 返回的指针在相应的值被删除后仍然有效从堆栈中。”从您的帖子看来,char* 似乎可能指向在表的生命周期内有效的内存,但是什么如果指针指向 Lua 对象中字符串的副本?这会令人惊讶,但唯一可靠的了解方式是查看 Lua 源代码。

不复制的另一个原因是自找麻烦(意思是,现在可以了,但可能会更改,恕不另行通知),是脚本中任何使您的假设无效的更改都将导致内存损坏而没有任何警告。也就是说,当 lua_ltostring 返回指针指向的内存被 gc 时,您的 C 代码甚至没有办法得到通知(以及获得通知的巧妙技巧,例如 __del 元方法,将招致他们自己的性能损失)。

那么回到优化的基础:您是否真的担心有争议的字符串副本将成为您应用程序中的一个瓶颈?因为如果没有,那就是过早的优化,并且可能会导致一个错误,从现在开始一年后,当您忘记了这个看似无辜的“捷径”时,很难隔离 :)

关于c - 是否需要为本地范围处理复制表字符串?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/25836825/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com