sol2/docs/source/api/make_reference.rst

make_object/make_reference
==========================
*create a value in the lua registry / on the Lua stack and return it*


.. code-block:: cpp
	:caption: function: make_reference
	:name: make-reference

	template <typename R = reference, bool should_pop = (R is not base of sol::stack_index), typename T>
	R make_reference(lua_State* L, T&& value);
	template <typename T, typename R = reference, bool should_pop = (R is base of sol::stack_index), typename... 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<stack_reference>` (or any of its typically derived types in sol), it will leave the pushed values on the stack.

.. code-block:: cpp
	:caption: function: make_object
	:name: make-object

	template <typename T>
	object make_object(lua_State* L, T&& value);
	template <typename T, typename... Args>
	object make_object(lua_State* L, Args&&... args);

Makes an object out of the value. It pushes it onto the stack, then pops it into the returned ``sol::object``. 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 implementation essentially defers to :ref:`sol::make_reference<make-reference>` with the specified arguments, ``R == object`` and ``should_pop == true``. It is preferred that one uses the :ref:`in_place object constructor instead<overloaded-object-constructor>`, since it's probably easier to deal with, but both versions will be supported for forever, since there's really no reason not to and people already have dependencies on ``sol::make_object``.