From eb0541d82a682147381e2197fc1a1d98f69e6e0e Mon Sep 17 00:00:00 2001 From: C3pa <41503714+C3pa@users.noreply.github.com> Date: Mon, 22 Jan 2024 08:44:39 +0100 Subject: [PATCH] Fix a typo in functions docs --- documentation/source/functions.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/source/functions.rst b/documentation/source/functions.rst index 762d4081..2ea0b3ba 100644 --- a/documentation/source/functions.rst +++ b/documentation/source/functions.rst @@ -67,7 +67,7 @@ You can change this behavior by defining ``SOL_FUNCTION_CALL_VALUE_SEMANTICS``, .. note:: - This also means that you should pass and receive arguments in certain ways to maximize efficiency. For example, ``sol::table``, ``sol::object``, ``sol::userdata`` and friends are cheap to copy, and should simply by taken as values. This includes primitive types like ``int`` and ``double``. However, C++ types -- if you do not want copies -- should be taken as ``const type&`` or ``type&``, to save on copies if it's important. Note that taking references from Lua also means you can modify the data inside of Lua directly, so be careful. Lua by default deals with things mostly by reference (save for primitive types). + This also means that you should pass and receive arguments in certain ways to maximize efficiency. For example, ``sol::table``, ``sol::object``, ``sol::userdata`` and friends are cheap to copy, and should simply be taken as values. This includes primitive types like ``int`` and ``double``. However, C++ types -- if you do not want copies -- should be taken as ``const type&`` or ``type&``, to save on copies if it's important. Note that taking references from Lua also means you can modify the data inside of Lua directly, so be careful. Lua by default deals with things mostly by reference (save for primitive types). When you bind a function to Lua, please take any pointer arguments as ``T*``, unless you specifically know you are going to match the exact type of the unique/shared pointer and the class it wraps. sol2 cannot support "implicit wrapped pointer casting", such as taking a ``std::shared_ptr`` when the function is passed a ``std::shared_ptr``. Sometimes it may work because the compiler might be able to line up your classes in such a way that raw casts work, but this is undefined behavior through and through and sol2 has no mechanisms by which it can make this safe and not blow up in the user's face.