diff options
Diffstat (limited to '3rdparty/sol2/docs/source/tutorial')
4 files changed, 27 insertions, 7 deletions
diff --git a/3rdparty/sol2/docs/source/tutorial/all-the-things.rst b/3rdparty/sol2/docs/source/tutorial/all-the-things.rst index fa9e73ac6c0..3695ac77fe2 100644 --- a/3rdparty/sol2/docs/source/tutorial/all-the-things.rst +++ b/3rdparty/sol2/docs/source/tutorial/all-the-things.rst @@ -47,6 +47,10 @@ running lua code int value = lua.script("return 54"); // value == 54 +To check the success of a loading operation: + +.. code-block:: cpp + // load file without execute sol::load_result script1 = lua.load_file("path/to/luascript.lua"); script1(); //execute @@ -59,6 +63,24 @@ running lua code // value2 == 24 +To check whether a script was successfully run or not (after loading is assumed to be successful): + +.. code-block:: cpp + + // execute and return result + sol::protected_function_result result1 = lua.do_string("return 24"); + if (result1.valid()) { + int value = result1; + // value == 24 + // yay! + } + else { + // ahhh :c + } + + +There is also ``lua.do_file("path/to/luascript.lua");``. + set and get variables --------------------- diff --git a/3rdparty/sol2/docs/source/tutorial/customization.rst b/3rdparty/sol2/docs/source/tutorial/customization.rst index 31fcad46568..5479c804115 100644 --- a/3rdparty/sol2/docs/source/tutorial/customization.rst +++ b/3rdparty/sol2/docs/source/tutorial/customization.rst @@ -108,6 +108,9 @@ A few things of note about the implementation: First, there's an auxiliary param You can make something pushable into Lua, but not get-able in the same way if you only specialize one part of the system. If you need to retrieve it (as a return using one or multiple values from Lua), you should specialize the ``sol::stack::getter`` template class and the ``sol::stack::checker`` template class. If you need to push it into Lua at some point, then you'll want to specialize the ``sol::stack::pusher`` template class. The ``sol::lua_size`` template class trait needs to be specialized for both cases, unless it only pushes 1 item, in which case the default implementation will assume 1. +.. note:: + + It is important to note here that the ``getter``, ``pusher`` and ``checker`` differentiate between a type ``T`` and a pointer to a type ``T*``. This means that if you want to work purely with, say, a ``T*`` handle that does not have the same semantics as just ``T``, you may need to specify checkers/getters/pushers for both ``T*`` and ``T``. The checkers for ``T*`` forward to the checkers for ``T``, but the getter for ``T*`` does not forward to the getter for ``T`` (e.g., because of ``int*`` not being quite the same as ``int``). In general, this is fine since most getters/checkers only use 1 stack point. But, if you're doing more complex nested classes, it would be useful to use ``tracking.last`` to understand how many stack indices the last getter/checker operation did and increment it by ``index + tracking.last`` after using a ``stack::check<..>( L, index, tracking)`` call. diff --git a/3rdparty/sol2/docs/source/tutorial/functions.rst b/3rdparty/sol2/docs/source/tutorial/functions.rst index 2b2f0e3ba61..5fa8d823fd3 100644 --- a/3rdparty/sol2/docs/source/tutorial/functions.rst +++ b/3rdparty/sol2/docs/source/tutorial/functions.rst @@ -338,4 +338,4 @@ It can be used like so, inconjunction with ``sol::this_state``: } -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 next stop in this tutorial is about :doc:`C++ types (usertypes) in Lua<cxx-in-lua>`!
\ No newline at end of file +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 next stop in this tutorial is about :doc:`C++ types (usertypes) in Lua<cxx-in-lua>`! If you need a bit more information about functions in the C++ side and how to best utilize arguments from C++, see :ref:`this note<function-argument-handling>`.
\ No newline at end of file diff --git a/3rdparty/sol2/docs/source/tutorial/getting-started.rst b/3rdparty/sol2/docs/source/tutorial/getting-started.rst index fd83e4fcb93..02fc2daadf0 100644 --- a/3rdparty/sol2/docs/source/tutorial/getting-started.rst +++ b/3rdparty/sol2/docs/source/tutorial/getting-started.rst @@ -5,14 +5,9 @@ Let's get you going with Sol! To start, you'll need to use a lua distribution of If you need help getting or building Lua, check out the `Lua page on getting started`_. Note that for Visual Studio, one can simply download the sources, include all the Lua library files in that project, and then build for debug/release, x86/x64/ARM rather easily and with minimal interference. Just make sure to adjust the Project Property page to build as a static library (or a DLL with the proper define set in the ``Preprocessor`` step). -After that, make sure you grab either the `single header file release`_, or just perform a clone of the `github repository here`_ and set your include paths up so that you can get at ``sol.hpp`` somehow. Note that we also have the latest version of the single header file with all dependencies included kept in the `repository as well`_. We recommend the single-header-file release, since it's easier to move around, manage and update if you commit it with some form of version control. If you use the github clone method and do not point to the `single/sol/sol.hpp`_ on your include files, you *must* update submodules in order to make sure Optional is present in the repository. Clone with: +After that, make sure you grab either the `single header file release`_, or just perform a clone of the `github repository here`_ and set your include paths up so that you can get at ``sol.hpp`` somehow. Note that we also have the latest version of the single header file with all dependencies included kept in the `repository as well`_. We recommend the single-header-file release, since it's easier to move around, manage and update if you commit it with some form of version control. You can also clone/submodule the repository and then point at the `single/sol/sol.hpp`_ on your include files path. Clone with: >>> git clone https://github.com/ThePhD/sol2.git ->>> git submodule update --init - -or, just run - ->>> git clone --recursive https://github.com/ThePhD/sol2.git When you're ready, try compiling this short snippet: |