StarMirror/sol2
1
0
Fork 0
mirror of https://github.com/ThePhD/sol2.git synced 2024-03-22 13:10:44 +08:00
Code Issues Projects Releases Wiki Activity

[ci-skip] update usertype docs so I have somewhere to point users when they make a derp

Browse Source
This commit is contained in:
ThePhD 2017-03-28 22:13:08 -04:00
parent b835e7d2c7
commit 6bc034c5a9
3 changed files with 11 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/source/features.rst
View File

@ -10,7 +10,7 @@ For the hard technical components of Lua and its ecosystem we support, here is t
what Sol supports
-----------------
* Support for Lua 5.1, 5.2, and 5.3. We achieve this through our :doc:`compatibility<compatibility>` header.
* Support for Lua 5.1, 5.2, and 5.3. We achieve this through our :doc:`compatibility<api/compatibility>` header.
* :doc:`Table<api/table>` support: setting values, getting values of multiple (different) types
- :doc:`Lazy evaluation<api/proxy>` for nested/chained queries

4
docs/source/safety.rst
View File

@ -3,6 +3,8 @@ safety
Sol was designed to be correct and fast, and in the pursuit of both uses the regular ``lua_to{x}`` functions of Lua rather than the checking versions (``lua_check{X}``) functions. The API defaults to paranoidly-safe alternatives if you have a ``#define SOL_CHECK_ARGUMENTS`` before you include Sol, or if you pass the ``SOL_CHECK_ARGUMENTS`` define on the build command for your build system. By default, it is off and remains off unless you define this, even in debug mode. The same goes for ``#define SOL_SAFE_USERTYPE``.
.. _config:
config
------
@ -41,4 +43,4 @@ As a side note, binding functions with default parameters does not magically bin
.. warning::
Do NOT save the return type of a :ref:`function_result<function-result>` with ``auto``, as in ``auto numwoof = woof(20);``, and do NOT store it anywhere. See :ref:`here<function-result-warning>`.
Do NOT save the return type of a :ref:`function_result<function-result>` with ``auto``, as in ``auto numwoof = woof(20);``, and do NOT store it anywhere. See :ref:`here<function-result-warning>`.

8
docs/source/usertypes.rst
View File

@ -13,6 +13,12 @@ To learn more about usertypes, visit:
The examples folder also has a number of really great examples for you to see. There are also some notes about guarantees you can find about usertypes, and their associated userdata, below:
* All usertypes are runtime extensible in both `Lua`_ and `C++`_
* Please note that the semi-colon is necessary to "automatically" pass the ``this``/``self`` argument to Lua methods
- ``obj:method_name()`` is how you call "member" methods in Lua
- It is purely syntactic sugar that passes the object name as the first argument to the ``method_name`` function
- ``my_obj:foo(bar, baz)`` is the same as ``my_obj.foo(my_obj, bar, baz)``
- **Please note** that one uses a semi-colon, and the other uses a dot, and forgetting to do this properly will crash your code
- There are safety defines outlined in the :ref:`safety page here<config>`
* You can push types classified as userdata before you register a usertype.
- You can register a usertype with the Lua runtime at any time sol2
- You can retrieve them from the Lua runtime as well through sol2
@ -30,6 +36,6 @@ The examples folder also has a number of really great examples for you to see. T
* Containers get pushed as special usertypes, but can be disabled if problems arise as detailed :doc:`here<api/containers>`.
* You can use bitfields but it requires some finesse on your part. We have an example to help you get started `here, that uses a few tricks`_.
.. _here that uses a few tricks: https://github.com/ThePhD/sol2/blob/develop/examples/usertype_bitfields.cpp
.. _here, that uses a few tricks: https://github.com/ThePhD/sol2/blob/develop/examples/usertype_bitfields.cpp
.. _Lua: https://github.com/ThePhD/sol2/blob/develop/examples/usertype_advanced.cpp#L81
.. _C++: https://github.com/ThePhD/sol2/blob/develop/examples/usertype_simple.cpp#L51