diff options
Diffstat (limited to 'deps/sol2/docs/source/api/nested.rst')
| -rw-r--r-- | deps/sol2/docs/source/api/nested.rst | 23 |
1 files changed, 0 insertions, 23 deletions
diff --git a/deps/sol2/docs/source/api/nested.rst b/deps/sol2/docs/source/api/nested.rst deleted file mode 100644 index 5d7fa87..0000000 --- a/deps/sol2/docs/source/api/nested.rst +++ /dev/null @@ -1,23 +0,0 @@ -nested -====== - - -.. code-block:: cpp - - template <typename T> - struct nested { - T& value() &; - const T& value() & const; - T&& value() &&; - }; - - -``sol::nested<...>`` is a template class similar to :doc:`sol::as_table<as_table>`, but with the caveat that every :doc:`container type<../containers>` within the ``sol::nested`` type will be retrieved as a table from lua. This is helpful when you need to receive C++-style vectors, lists, and maps nested within each other: all of them will be deserialized from lua using table properties rather than anything else. - -Note that any caveats with Lua tables apply the moment it is serialized, and the data cannot be gotten out back out in C++ as a C++ type. You can deserialize the Lua table into something explicitly using the ``sol::as_table_t`` marker for your get and conversion operations using sol. At that point, the returned type is deserialized **from** a table, meaning you cannot reference any kind of C++ data directly as you do with regular userdata/usertypes. *All C++ type information is lost upon serialization into Lua.* - -The example provides a very in-depth look at both ``sol::as_table<T>`` and ``sol::nested<T>``, and how the two are equivalent. - -.. literalinclude:: ../../../examples/source/containers_as_table.cpp - :linenos: - :lines: 1-30,56-61,63-68,70- |