From cf0802c6e08778047cb6d827bf33bcb9a8ee5c92 Mon Sep 17 00:00:00 2001 From: ThePhD Date: Sat, 6 Aug 2016 00:41:17 -0400 Subject: [PATCH] [ci-skip] Dat documentation --- docs/source/api/make_reference.rst | 4 ++-- docs/source/tutorial/functions.rst | 4 +--- 2 files changed, 3 insertions(+), 5 deletions(-) diff --git a/docs/source/api/make_reference.rst b/docs/source/api/make_reference.rst index 39ce6320..2686a3ab 100644 --- a/docs/source/api/make_reference.rst +++ b/docs/source/api/make_reference.rst @@ -7,10 +7,10 @@ Create a value on the Lua stack and return it :caption: function: make_reference :name: make-reference - template + template R make_reference(lua_State* L, T&& value); template - R make_object(lua_State* L, Args&&... args); + R make_reference(lua_State* L, Args&&... args); Makes an ``R`` out of the value. The first overload deduces the type from the passed in argument, the second allows you to specify a template parameter and forward any relevant arguments to ``sol::stack::push``. The type figured out for ``R`` is what is referenced from the stack. This allows you to request arbitrary pop-able types from Sol and have it constructed from ``R(lua_State* L, int stack_index)``. If the template boolean ``should_pop`` is ``true``, the value that was pushed will be popped off the stack. It defaults to popping, but if it encounters a type such as :doc:`sol::stack_reference` (or any of its typically derived types in Sol), it will leave the pushed values on the stack. diff --git a/docs/source/tutorial/functions.rst b/docs/source/tutorial/functions.rst index 0b38745e..245a83ee 100644 --- a/docs/source/tutorial/functions.rst +++ b/docs/source/tutorial/functions.rst @@ -162,7 +162,7 @@ This is useful for functions which can take multiple types and need to behave di .. note:: - Function object ``obj`` -- a struct with a ``return_type operator()( ... )`` member defined on them, like all C++ lambdas -- are not interpreted as functions when you use ``set`` for ``mytable.set( key, value )``. This only happens automagically with ``mytable[key] = obj``. To be explicit about wanting a struct to be interpreted as a function, use ``mytable.set_function( key, func_value );``. + Function object ``obj`` -- a struct with a ``return_type operator()( ... )`` member defined on them, like all C++ lambdas -- are not interpreted as functions when you use ``set`` for ``mytable.set( key, value )``. This only happens automagically with ``mytable[key] = obj``. To be explicit about wanting a struct to be interpreted as a function, use ``mytable.set_function( key, func_value );``. You can be explicit about wanting a function as well by using the :doc:`sol::as_function<../api/as_function>` call. Getting a function from Lua @@ -293,7 +293,5 @@ You can also return mutiple items yourself from a C++-bound function. Here, we'r Note here that we use :doc:`sol::object<../api/object>` to transport through "any value" that can come from Lua. You can also use ``sol::make_object`` to create an object from some value, so that it can be returned into Lua as well. -Finally, note that there's a caveat if you use the regular :ref:`sol::table::set` function to set a lambda / callable C++ struct (see :doc:`here for more details<../api/as_function>`). - This covers almost everything you need to know about Functions and how they interact with Sol. For some advanced tricks and neat things, check out :doc:`sol::this_state<../api/this_state>` and :doc:`sol::variadic_args<../api/variadic_args>`. The last stop in this tutorial is about :doc:`C++ types (usertypes) in Lua`! \ No newline at end of file