From bd3fe0cac583739bc0d7c4b5c8f301bb350abca0 Mon Sep 17 00:00:00 2001 From: Andy Belle-Isle Date: Fri, 30 Aug 2019 00:19:31 -0400 Subject: Renamed lib to deps so github will ignore it for language stats --- deps/sol2/docs/source/api/nested.rst | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 deps/sol2/docs/source/api/nested.rst (limited to 'deps/sol2/docs/source/api/nested.rst') diff --git a/deps/sol2/docs/source/api/nested.rst b/deps/sol2/docs/source/api/nested.rst new file mode 100644 index 0000000..5d7fa87 --- /dev/null +++ b/deps/sol2/docs/source/api/nested.rst @@ -0,0 +1,23 @@ +nested +====== + + +.. code-block:: cpp + + template + struct nested { + T& value() &; + const T& value() & const; + T&& value() &&; + }; + + +``sol::nested<...>`` is a template class similar to :doc:`sol::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`` and ``sol::nested``, and how the two are equivalent. + +.. literalinclude:: ../../../examples/source/containers_as_table.cpp + :linenos: + :lines: 1-30,56-61,63-68,70- -- cgit v1.2.3