最近因为在公司的项目中接手了Lua脚本模块的开发，所以研究了很多关于Lua脚本的东西，秉着“多看多想多记”的原则，我时刻敦促自己要及时记录下遇到的一些问题和想法。 在Lua中，几乎所有的东西都是围绕着lua_State转，所以，一般我们都会写一个类来封装管理它，比如： 这很好，不过它不是指针安全的。试想，如果一个LuaObject对象被复制，结果将会怎样。 上面这段代码将会导致运行时crash，因为luaObject1和luaObject事实上指向了同一块lua_State，这样当luaObject1和luaObject2被析构时，lua_State会被两次lua_close，这不crash才怪呢！ 事实是，当一个类包含了一个指针时，我们就需要开始变得格外谨慎，除了在构造函数和析构函数中要处理指针的初始化和清理外，我们还需要考虑深拷贝（deep copy），浅拷贝（shallow copy)）的问题。如果使用编译器默认生成的拷贝构造函数，它只会浅拷贝指针，而指针所指向的内存区域不会被拷贝。就像上面一样，两个LuaObject实则共享了一个lua_State。 那该如何处理让管理LuaObject类的指针安全呢，深拷贝？厄，首先我也没有深究深度拷贝lua_State具体该如何完成，不过我猜想这可是一个复杂而重型的操作，仅仅为了带来指针安全而选择此可不是一个明智的选择。 如果你是开发LuaObject类的程序员，也许你会对使用LuaObject的程序员（或许有时使用者就是你自己）说：“你不要对它进行拷贝操作不就OK了”，但这是一种严重不负责任的行为，因为这种皮球会越踢越远的。比如，程序员A使用了你的LuaObject类，他写了一个包含LuaObject的指针的类，同样A也不考虑拷贝指针安全问题，然后A又将它的类传递给了B，B封装了A的类指针，然后传递给了C，接着如此重复，C再给D，D再给E，最后E在对类进行拷贝操作时，程序crash掉了，因为在某个最底层，他们共享了lua_State。不过因为这时候已经嵌套了这么多层，E程序员或许根本不知道也不关心什么是LuaObject（他只跟D的类打交道）。这时，要想追踪到BUG之源——万恶的不考虑指针安全的LuaObject，已经非常困难了，God bless you all. 事实是，如果你不想让你的类被复制，你就应该明确而显示的禁止它。其实lua_State的这个问题非常类似于Effective C++书中的第14个条款中所提到的问题：在资源管理类中小心copying行为。对于这个问题，书中提供了两种解决方案。第一种就是禁止复制。第二种则是对底层资源的“引用计数法”（reference count）。 第一种禁止复制很简单。（关于Uncopyable） 第二种则是使用智能指针来封装lua_State，我们可以使用boost的shared_ptr来封装lua_State，即shared_ptr< lua_State > m_L。如何对m_L进行初始化是另一个需要注意的问题，如果使用shared_ptr的常见初始化形式：m_L = shared_ptr< lua_State >( luaL_newstate() )，这样是不对的，因为在这种形式下，当lua_State的计数变为0时，shared_ptr会去调用lua_State的的析构函数，这显然是错误的，对lua_State的释放动作是lua_close而不是删除。事实上，这样编译器也无法通过，如果这么写，会报出“use of undefined type ‘lua_State’”的错误，提示lua_State是一个非完成的类型（incomplete type）。 我们应该为shared_ptr的初始化传入一个删除器（deleter）。很显然，lua_State的deleter是lua_close()函数，这样最终的代码如下。 这样再回到前面拷贝的那个例子，luaObject1和luaObject2共同引用了一个lua_State，但因为使用了shared_ptr，所以只有在lua_State的引用次数变为0时，它的deleter（这里是lua_close）才会被调用，安全了！ 在我的项目中，因为没有使用boost库，也没有提供任何智能指针，所以使用禁止复制来保证安全。