I have a simple program that reads a set of Lua files for plugins and creates a std::vector containing the sol::state and some std::functions that point to the sol::state. This crashes because the std::vector moves the sol::state but the captured function wrappers keep references to it.
As far as I can tell, it is not documented anywhere that you should not move a sol::state (I expected the std::functions to capture references to the inner Lua state, not to the sol::state itself. Deleting the move and copy constructors on sol::state would prevent this kind of thing compiling, but may cause problems if people expect to keep the state but not capture pointers into it.
At the very least, it would be good if the API documentation conveyed the ownership model and explicitly told you that std::function<...> f = lua["..."] is contains pointers to lua and it is not safe to move lua.
I have a simple program that reads a set of Lua files for plugins and creates a
std::vectorcontaining thesol::stateand somestd::functions that point to thesol::state. This crashes because thestd::vectormoves thesol::statebut the captured function wrappers keep references to it.As far as I can tell, it is not documented anywhere that you should not move a
sol::state(I expected thestd::functions to capture references to the inner Lua state, not to thesol::stateitself. Deleting the move and copy constructors onsol::statewould prevent this kind of thing compiling, but may cause problems if people expect to keep the state but not capture pointers into it.At the very least, it would be good if the API documentation conveyed the ownership model and explicitly told you that
std::function<...> f = lua["..."]is contains pointers toluaand it is not safe to movelua.