begin migrating benchmarks and preparing documentation for sol3

This commit is contained in:
ThePhD 2018-05-17 02:31:28 -04:00
parent daf9de3007
commit 4f366a17a9
86 changed files with 307371 additions and 28164 deletions

View File

@ -1,7 +1,7 @@
# # # # sol2
# The MIT License (MIT)
#
# Copyright (c) 2013-2017 Rapptz, ThePhD, and contributors
# Copyright (c) 2013-2018 Rapptz, ThePhD, and contributors
#
# Permission is hereby granted, free of charge, to any person obtaining a copy of
# this software and associated documentation files (the "Software"), to deal in

2
.gitignore vendored
View File

@ -1,7 +1,7 @@
# # # # sol2
# The MIT License (MIT)
#
# Copyright (c) 2013-2017 Rapptz, ThePhD, and contributors
# Copyright (c) 2013-2018 Rapptz, ThePhD, and contributors
#
# Permission is hereby granted, free of charge, to any person obtaining a copy of
# this software and associated documentation files (the "Software"), to deal in

View File

@ -1,6 +1,6 @@
The MIT License (MIT)
Copyright (c) 2013-2017 Rapptz, ThePhD, and contributors
Copyright (c) 2013-2018 Rapptz, ThePhD, and contributors
Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal in

View File

@ -23,7 +23,6 @@ Browse the various function and classes :doc:`Sol<../index>` utilizes to make yo
nested
as_table
usertype
simple_usertype
usertype_memory
unique_usertype_traits
tie

View File

@ -1,38 +0,0 @@
simple_usertype<T>
==================
*structures and classes from C++ made available to Lua code (simpler)*
This usertype is no difference from :doc:`regular usertype<usertype>`, but allows much of its work to be done at runtime instead of compile-time. You can reduce compilation times from a plain ``usertype`` when you have an exceedingly bulky registration listing.
You can set functions incrementally to reduce compile-time burden with ``simple_usertype`` as well, as shown in `this example`_. This means both adding incrementally during registration and even adding at runt=time.
You can add functions to both regular and simple usertypes afterwards by adding items to the metatable directly at runtime (e.g., by accessing the named metatable yourself and setting functions on it).
.. note::
You cannot add functions to an individual object. You can only add functions to the whole class / usertype.
Some developers used ``simple_usertype`` in older versions to have variables automatically be functions. To achieve this behavior, wrap the desired variable into :doc:`sol::as_function<as_function>`.
The performance `seems to be good enough`_ (see below graphs as well) to not warn about any implications of having to serialize things at runtime. You do run the risk of using (slightly?) more memory, since variables and functions need to be stored differently and separately from the metatable data itself like with a regular ``usertype``. The goal here was to avoid compiler complaints about too-large usertypes (some individuals needed to register 190+ functions, and the compiler choked from the templated implementation of ``usertype``). As of Sol 2.14, this implementation has been heavily refactored to allow for all the same syntax and uses of usertype to apply here, with no caveats/exceptions.
.. image:: /media/bench/lua_bench_graph_member_function_calls_(simple).png
:target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua_bench_graph_member_function_calls_(simple).png
:alt: bind several member functions to an object and call them in Lua code
.. image:: /media/bench/lua_bench_graph_userdata_variable_access_(simple).png
:target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua_bench_graph_userdata_variable_access_(simple).png
:alt: bind a member variable to an object and modify it with Lua code
.. image:: /media/bench/lua_bench_graph_many_userdata_variables_access_last_registered_(simple).png
:target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua_bench_graph_many_userdata_variables_access_last_registered_(simple).png
:alt: bind MANY member variables to an object and modify it with Lua code
.. _seems to be good enough: https://github.com/ThePhD/sol2/issues/202#issuecomment-246767629
.. _this example: https://github.com/ThePhD/sol2/blob/develop/examples/usertype_simple.cpp

View File

@ -147,19 +147,6 @@ This function returns the size of a table. It is only well-defined in the case o
This class of functions creates a new :doc:`usertype<usertype>` with the specified arguments, providing a few extra details for constructors. After creating a usertype with the specified argument, it passes it to :ref:`set_usertype<set_usertype>`.
.. code-block:: cpp
:caption: function: setting a simple usertype
:name: new-simple-usertype
template<typename Class, typename... Args>
table& new_simple_usertype(const std::string& name, Args&&... args);
template<typename Class, typename CTor0, typename... CTor, typename... Args>
table& new_simple_usertype(const std::string& name, Args&&... args);
template<typename Class, typename... CArgs, typename... Args>
table& new_simple_usertype(const std::string& name, constructors<CArgs...> ctor, Args&&... args);
This class of functions creates a new :doc:`simple usertype<simple_usertype>` with the specified arguments, providing a few extra details for constructors and passing the ``sol::simple`` tag as well. After creating a usertype with the specified argument, it passes it to :ref:`set_usertype<set_usertype>`.
.. code-block:: cpp
:caption: function: creating an enum
:name: new-enum

View File

@ -194,22 +194,10 @@ Otherwise, the following is used to specify functions to bind on the specific us
- Tells a usertype what its base classes are. You need this to have derived-to-base conversions work properly. See :ref:`inheritance<usertype-inheritance>`
usertype arguments - simple usertype
++++++++++++++++++++++++++++++++++++
* ``sol::simple``
- Only allowed as the first argument to the usertype constructor, must be accompanied by a ``lua_State*``
- This tag triggers the :doc:`simple usertype<simple_usertype>` changes / optimizations
- Only supported when directly invoking the constructor (e.g. not when calling ``sol::table::new_usertype`` or ``sol::table::new_simple_usertype``)
- Should probably not be used directly. Use ``sol::table::new_usertype`` or ``sol::table::new_simple_usertype`` instead
runtime functions
-----------------
You can add functions at runtime **to the whole class** (not to individual objects). Set a name under the metatable name you bound using ``new_usertype``/``new_simple_usertype`` to an object. For example:
You can add functions at runtime **to the whole class** (not to individual objects). Set a name under the metatable name you bound using ``new_usertype`` to an object. For example:
.. literalinclude:: ../../../examples/docs/runtime_extension.cpp
:caption: runtime_extension.cpp
@ -267,7 +255,7 @@ Register the base classes explicitly.
automagical usertypes
---------------------
Usertypes automatically register special functions, whether or not they're bound using `new(_simple)_usertype`. You can turn this off by specializing the ``sol::is_automagical<T>`` template trait:
Usertypes automatically register special functions, whether or not they're bound using `new_usertype`. You can turn this off by specializing the ``sol::is_automagical<T>`` template trait:
.. code-block:: cpp
@ -286,10 +274,6 @@ While overloading is supported regardless of inheritance caveats or not, the cur
compilation speed
-----------------
.. note::
If you find that compilation times are too long and you're only binding member functions, consider perhaps using :doc:`simple usertypes<simple_usertype>`. This can reduce compile times (but may cost memory size and speed). See the simple usertypes documentation for more details.
.. note::
MSVC and clang/gcc may need additional compiler flags to handle compiling extensive use of usertypes. See: :ref:`the error documentation<compilation_errors_warnings>` for more details.

View File

@ -8,87 +8,97 @@ Here are measurements of the *overhead that libraries impose around the Lua C AP
These are some informal and formal benchmarks done by both the developers of sol and other library developers / users. We leave you to interpret the data as you see fit.
* `lua_binding_benchmarks`_ by satoren (developer of `kaguya`_) (`Sol`_ is the "sol2" entry)
* `lua-bench`_ by ThePhD (developer of `Sol`_)
* `lua_binding_benchmarks`_ by satoren (developer of `kaguya`_) (`sol`_ is the "sol2" entry)
* `lua-bindings-shootout`_ by ThePhD (developer of `sol`_)
As of the writing of this documentation (August 8th, 2017), :doc:`Sol<index>` (Sol2) seems to take the cake in most categories for speed! Below are some graphs from `lua-bench`_. You can read the benchmarking code there if you think something was done wrong, and submit a pull requests or comment on something to make sure that ThePhD is being honest about his work. All categories are the performance of things described at the top of the :doc:`feature table<features>`.
As of the writing of this documentation (May 17th, 2018), :doc:`sol<index>` seems to take the cake in most categories for speed! Below are some graphs from `lua-bindings-shootout`_. You can read the benchmarking code there if you think something was done wrong, and submit a pull requests or comment on something to make sure that ThePhD is being honest about his work. All categories are the performance of things described at the top of the :doc:`feature table<features>`.
Note that Sol here makes use of its more performant variants (see :doc:`c_call<api/c_call>` and others), and ThePhD also does his best to make use of the most performant variants for other frameworks by disabling type checks where possible as well (Thanks to Liam Devine of OOLua for explaining how to turn off type checks in OOLua).
Note that sol here makes use of its more performant variants (see :doc:`c_call<api/c_call>` and others), and ThePhD also does his best to make use of the most performant variants for other frameworks by disabling type checks where possible as well (Thanks to Liam Devine of OOLua for explaining how to turn off type checks in OOLua).
Bars go up to the average execution time. Lower is better. Reported times are for the desired operation run through `nonius`_. Results are sorted from top to bottom by best to worst. Note that there are error bars to show potential variance in performance: generally, same-sized errors bars plus very close average execution time implies no significant difference in speed, despite the vastly different abstraction techniques used.
.. image:: /media/bench/lua_bench_graph_member_function_calls.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua_bench_graph_member_function_calls.png
.. image:: /media/bench/member_function_call.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bindings-shootout/master/benchmark_results/member%20function%20call.png
:alt: bind several member functions to an object and call them in Lua code
.. image:: /media/bench/lua_bench_graph_userdata_variable_access.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua_bench_graph_userdata_variable_access.png
.. image:: /media/bench/userdata_variable_access.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bindings-shootout/master/benchmark_results/userdata%20variable%20access.png
:alt: bind a variable to an object and call it in Lua code
.. image:: /media/bench/lua_bench_graph_many_userdata_variables_access.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua_bench_graph_many_userdata_variables_access.png
:alt: bind MANY variables to an object and call it in Lua code
.. image:: /media/bench/userdata_variable_access_large.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bindings-shootout/master/benchmark_results/userdata%20variable%20access%20large.png
:alt: bind MANY variables to an object and access them in Lua code
.. image:: /media/bench/lua_bench_graph_c_function_through_lua.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua_bench_graph_c_function_through_lua.png
.. image:: /media/bench/c_function_through_lua_in_c.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bindings-shootout/master/benchmark_results/c%20function%20through%20lua%20in%20c.png
:alt: retrieve a C function bound in Lua and call it from C++
.. image:: /media/bench/lua_bench_graph_stateful_c_function.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua_bench_graph_stateful_c_function.png
.. image:: /media/bench/stateful_function_object.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bindings-shootout/master/benchmark_results/stateful%20function%20object.png
:alt: bind a stateful C function (e.g., a mutable lambda), retrieve it, and call it from C++
.. image:: /media/bench/lua_bench_graph_c_function.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua_bench_graph_c_function.png
.. image:: /media/bench/c_function.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bindings-shootout/master/benchmark_results/c%20function.png
:alt: call a C function through Lua code
.. image:: /media/bench/lua_bench_graph_lua_function.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua_bench_graph_lua_function.png
.. image:: /media/bench/lua_function_in_c.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bindings-shootout/master/benchmark_results/lua%20function%20in%20c.png
:alt: retrieve a plain Lua function and call it from C++
.. image:: /media/bench/lua_bench_graph_multi_return.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua_bench_graph_multi_return.png
.. image:: /media/bench/multi_return.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bindings-shootout/master/benchmark_results/multi%20return.png
:alt: return mutliple objects from C++ using std::tuple or through a library-defined mechanism
.. image:: /media/bench/lua_bench_graph_global_get.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua_bench_graph_global_get.png
.. image:: /media/bench/multi_return_lua.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bindings-shootout/master/benchmark_results/multi%20return%20lua.png
:alt: return mutliple objects from C++ using std::tuple or through a library-defined mechanism and use it in Lua
.. image:: /media/bench/table_global_string_get.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bindings-shootout/master/benchmark_results/table%20global%20string%20get.png
:alt: retrieve a value from the global table
.. image:: /media/bench/lua_bench_graph_global_set.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua_bench_graph_global_set.png
.. image:: /media/bench/table_global_string_set.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bindings-shootout/master/benchmark_results/table%20global%20string%20set.png
:alt: set a value into the global table
.. image:: /media/bench/lua_bench_graph_table_chained_get.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua_bench_graph_table_chained_get.png
.. image:: /media/bench/table_chained_get.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bindings-shootout/master/benchmark_results/table%20chained%20get.png
:alt: measures the cost of doing consecutive lookups into a table that exists from C++; some libraries fail here because they do not do lazy evaluation or chaining properly
.. image:: /media/bench/lua_bench_graph_table_get.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua_bench_graph_table_get.png
.. image:: /media/bench/table_get.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bindings-shootout/master/benchmark_results/table%20get.png
:alt: measures the cost of retrieving a value from a table in C++; this nests 1 level so as to not be equivalent to any measured global table get optimzations
.. image:: /media/bench/lua_bench_graph_table_chained_set.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua_bench_graph_table_chained_set.png
.. image:: /media/bench/table_chained_set.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bindings-shootout/master/benchmark_results/table%20chained%20set.png
:alt: measures the cost of doing consecutive lookups into a table that exists from C++ and setting the final value; some libraries fail here because they do not do lazy evaluation or chaining properly
.. image:: /media/bench/lua_bench_graph_table_set.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua_bench_graph_table_set.png
.. image:: /media/bench/table_set.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bindings-shootout/master/benchmark_results/table%20set.png
:alt: measures the cost of setting a value into a table in C++; this nests 1 level so as to not be equivalent to any measured global table set optimzations
.. image:: /media/bench/lua_bench_graph_return_userdata.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua_bench_graph_return_userdata.png
.. image:: /media/bench/return_userdata.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bindings-shootout/master/benchmark_results/return%20userdata.png
:alt: bind a C function which returns a custom class by-value and call it through Lua code
.. image:: /media/bench/lua_bench_graph_get_optional.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua_bench_graph_get_optional.png
.. image:: /media/bench/optional_failure.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bindings-shootout/master/benchmark_results/optional%20failure.png
:alt: retrieve an item from a table that does not exist in Lua and check for its existence (testing the cost of the failure case)
.. image:: /media/bench/lua_bench_graph_base_from_derived.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bench/master/lua%20-%20results/lua_bench_graph_base_from_derived.png
.. image:: /media/bench/optional_half_failure.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bindings-shootout/master/benchmark_results/optional%20half%20failure.png
:alt: retrieve an item from a table that does not exist in Lua and check for its existence (testing the cost of the first level success, second level failure case)
.. image:: /media/bench/optional_success.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bindings-shootout/master/benchmark_results/optional%20success.png
:alt: retrieve an item from a table that does not exist in Lua and check for its existence (testing the cost of the success case)
.. image:: /media/bench/base_derived.png
:target: https://raw.githubusercontent.com/ThePhD/lua-bindings-shootout/master/benchmark_results/base%20derived.png
:alt: retrieve base class pointer out of Lua without knowing exact derived at compile-time, and have it be correct for multiple-inheritance
.. _lua-bench: https://github.com/ThePhD/lua-bench
.. _lua-bindings-shootout: https://github.com/ThePhD/lua-bindings-shootout
.. _lua_binding_benchmarks: http://satoren.github.io/lua_binding_benchmark/
.. _kaguya: https://github.com/satoren/kaguya
.. _Sol: https://github.com/ThePhD/sol2
.. _sol: https://github.com/ThePhD/sol2
.. _nonius: https://github.com/rmartinho/nonius/

View File

@ -1,17 +1,17 @@
supported compilers, binary size, compile time
==============================================
getting good final product out of sol2
--------------------------------------
getting good final product out of sol
-------------------------------------
supported compilers
-------------------
GCC 7.x is now out alongside Visual Studio 2017. This means that `sol2 release v2.20.0`_ is the current version of the code targeted at the older compilers not listed below. Newer code will be targeted at working with the following compilers and leveraging their features, possibly taking advantage of whatever C++17 features are made available by the compilers and standard libraries bundled by-default with them.
GCC 7.x is now out alongside Visual Studio 2018. This means that `sol release v2.20.1`_ is the current version of the code targeted at the older compilers not listed below. Newer code will be targeted at working with the following compilers and leveraging their features, possibly taking advantage of whatever C++17 features are made available by the compilers and standard libraries bundled by-default with them.
``v2.18.3`` supports:
``v2.20.1`` supports:
* VC++
- Visual Studio 2017
- Visual Studio 2018
- Visual Studio 2015 (Latest updates)
* GCC (includes MinGW)
- v7.x
@ -32,22 +32,24 @@ Newer features will be targeted at the following compilers:
* VC++
- Visual Studio vNext
- Visual Studio 2017
- Visual Studio 2018
* GCC (includes MinGW)
- v8.x
- v7.x
* Clang
- v7.x
- v6.x
* Clang
- v5.x
- v4.x
- v3.9.x
- v3.8.x
Note that Visual Studio's 2017 Community Edition is absolutely free now, and installs faster and easier than ever before. It also removes a lot of hacky work arounds and formally supports decltype SFINAE.
Note that Visual Studio's 2018 Community Edition is absolutely free now, and installs faster and easier than ever before. It also removes a lot of hacky work arounds and formally supports decltype SFINAE.
MinGW's GCC version 7.x of the compiler fixes a long-standing derp in the <codecvt> header that swapped the endianness of utf16 and utf32 strings.
Clang 3.4, 3.5 and 3.6 have many bugs we have run into when developing sol2 and that have negatively impacted users for a long time now.
We encourage all users to upgrade immediately. If you need old code for some reason, use `sol2 release v2.20.0`_: otherwise, always grab sol2's latest.
We encourage all users to upgrade immediately. If you need old code for some reason, use `sol release v2.20.1`_: otherwise, always grab sol2's latest.
feature support
@ -81,8 +83,6 @@ Here are some notes on achieving better compile times without sacrificing too mu
- Remember that the usertype binding ends up being serialized into the Lua state, so you never need them to appear in a header and cause that same compilation overhead for every compiled unit in your project.
* Consider placing groups of bindings in multiple different translation units (multiple C++ source files) so that only part of the bindings are recompiled when you have to change the bindings.
- Avoid putting your bindings into headers: it *will* slow down your compilation
* For extremely large usertypes, consider using :doc:`simple_usertype<api/simple_usertype>`.
- It performs much more work at runtime rather than compile-time, and should still give comparative performance (but it loses out in some cases for variable bindings or when you bind all functions to a usertype).
* If you are developing a shared library, restrict your overall surface area by specifically and explicitly marking functions as visible and exported and leaving everything else as hidden or invisible by default
* For people who already have a tool that retrieves function signatures and arguments, it might be in your best interest to hook into that tool or generator and dump out the information once using sol2's lower-level abstractions. An `issue describing preliminary steps can be found here`_.
@ -95,6 +95,6 @@ The next step for Sol from a developer standpoint is to formally make the librar
Hopefully, as things progress, we move things forward.
.. _sol2 release v2.18.3: https://github.com/ThePhD/sol2/releases/tag/v2.20.0
.. _sol release v2.20.1: https://github.com/ThePhD/sol2/releases/tag/v2.20.1
.. _issue describing preliminary steps can be found here: https://github.com/ThePhD/sol2/issues/436#issuecomment-312021508
.. _this issue here: https://github.com/ThePhD/sol2/issues/426

View File

@ -47,7 +47,7 @@ master_doc = 'index'
# General information about the project.
project = 'Sol'
copyright = '2017, ThePhD'
copyright = '2018, ThePhD'
author = 'ThePhD'
# The version info for the project you're documenting, acts as replacement for
@ -55,9 +55,9 @@ author = 'ThePhD'
# built documents.
#
# The short X.Y version.
version = '2.20'
version = '3.0'
# The full version, including alpha/beta/rc tags.
release = '2.20.1'
release = '3.0.0-alpha'
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.

View File

@ -20,7 +20,7 @@ A myriad of compiler errors can occur when something goes wrong. Here is some ba
* If there are a myriad of errors relating to ``std::index_sequence``, type traits, and other ``std::`` members, it is likely you have not turned on your C++14 switch for your compiler. Visual Studio 2015 turns these on by default, but g++ and clang++ do not have them as defaults and you should pass the flag ``--std=c++1y`` or ``--std=c++14``, or similar for your compiler.
* If you are pushing a non-primitive type into Lua, you may get strange errors about initializer lists or being unable to initializer a ``luaL_Reg``. This may be due to :ref:`automatic function and operator registration<automagical-registration>`. :ref:`Disabling it<automagical>` may help.
* Sometimes, a generated usertype can be very long if you are binding a lot of member functions. You may end up with a myriad of warnings about debug symbols being cut off or about ``__LINE_VAR`` exceeding maximum length. You can silence these warnings safely for some compilers.
* Template depth errors may also be a problem on earlier versions of clang++ and g++. Use ``-ftemplate-depth`` compiler flag and specify really high number (something like 2048 or even double that amount) to let the compiler work freely. Also consider potentially using :doc:`simple usertypes<api/simple_usertype>` to save compilation speed.
* Template depth errors may also be a problem on earlier versions of clang++ and g++. Use ``-ftemplate-depth`` compiler flag and specify really high number (something like 2048 or even double that amount) to let the compiler work freely.
* When using usertype templates extensively, MSVC may invoke `compiler error C1128 <https://msdn.microsoft.com/en-us/library/8578y171.aspx>`_ , which is solved by using the `/bigobj compilation flag <https://msdn.microsoft.com/en-us/library/ms173499.aspx>`_.
* If you have a move-only type, that type may need to be made ``readonly`` if it is bound as a member variable on a usertype or bound using ``state_view::set_function``. See :doc:`sol::readonly<api/readonly>` for more details.
* Assigning a ``std::string`` or a ``std::pair<T1, T2>`` using ``operator=`` after it's been constructed can result in compiler errors when working with ``sol::function`` and its results. See `this issue for fixes to this behavior`_.

View File

@ -1,18 +1,19 @@
.. Sol documentation master file, created by
.. sol documentation master file, created by
sphinx-quickstart on Mon Feb 29 21:49:51 2016.
You can adapt this file completely to your liking, but it should at least
contain the root `toctree` directive.
.. image:: media/sol.png
:target: https://github.com/ThePhD/sol2
:alt: sol2 repository
:alt: sol repository
:align: center
Sol |version|
sol |version|
=============
*a fast, simple C++ and Lua Binding*
When you need to hit the ground running with Lua and C++, `Sol`_ is the go-to framework for high-performance binding with an easy to use API.
When you need to hit the ground running with Lua and C++, `sol`_ is the go-to framework for high-performance binding with an easy to use API.
get going:
----------

Binary file not shown.

After

Width:  |  Height:  |  Size: 51 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 50 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 52 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 51 KiB

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

Binary file not shown.

Before

Width:  |  Height:  |  Size: 95 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 70 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 155 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 150 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 76 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 116 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 107 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 177 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 82 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 84 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 102 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 137 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 156 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 146 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 137 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 113 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 107 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 106 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 99 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 93 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 102 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 100 KiB

File diff suppressed because it is too large Load Diff

Binary file not shown.

After

Width:  |  Height:  |  Size: 54 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 56 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 53 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 66 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 46 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 49 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 51 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 52 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 51 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 48 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 48 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 44 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 50 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 50 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 44 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 53 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 52 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 53 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 30 KiB

After

Width:  |  Height:  |  Size: 10 KiB

View File

@ -55,7 +55,7 @@ To run Lua code but have an error handler in case things go wrong:
.. literalinclude:: ../../../examples/tutorials/quick_n_dirty/running_lua_code.cpp
:linenos:
:lines: 28-39,47-49
:lines: 28-39,47-
running lua code (low-level)

View File

@ -1,7 +1,7 @@
# # # # sol2
# The MIT License (MIT)
#
# Copyright (c) 2013-2017 Rapptz, ThePhD, and contributors
# Copyright (c) 2013-2018 Rapptz, ThePhD, and contributors
#
# Permission is hereby granted, free of charge, to any person obtaining a copy of
# this software and associated documentation files (the "Software"), to deal in

View File

@ -1,7 +1,7 @@
# # # # sol2
# The MIT License (MIT)
#
# Copyright (c) 2013-2017 Rapptz, ThePhD, and contributors
# Copyright (c) 2013-2018 Rapptz, ThePhD, and contributors
#
# Permission is hereby granted, free of charge, to any person obtaining a copy of
# this software and associated documentation files (the "Software"), to deal in

View File

@ -1,7 +1,7 @@
# # # # sol2
# The MIT License (MIT)
#
# Copyright (c) 2013-2017 Rapptz, ThePhD, and contributors
# Copyright (c) 2013-2018 Rapptz, ThePhD, and contributors
#
# Permission is hereby granted, free of charge, to any person obtaining a copy of
# this software and associated documentation files (the "Software"), to deal in

View File

@ -1,7 +1,7 @@
# # # # sol2
# The MIT License (MIT)
#
# Copyright (c) 2013-2017 Rapptz, ThePhD, and contributors
# Copyright (c) 2013-2018 Rapptz, ThePhD, and contributors
#
# Permission is hereby granted, free of charge, to any person obtaining a copy of
# this software and associated documentation files (the "Software"), to deal in

View File

@ -1,7 +1,7 @@
# # # # sol2
# The MIT License (MIT)
#
# Copyright (c) 2013-2017 Rapptz, ThePhD, and contributors
# Copyright (c) 2013-2018 Rapptz, ThePhD, and contributors
#
# Permission is hereby granted, free of charge, to any person obtaining a copy of
# this software and associated documentation files (the "Software"), to deal in

View File

@ -1,7 +1,7 @@
# # # # sol2
# The MIT License (MIT)
#
# Copyright (c) 2013-2017 Rapptz, ThePhD, and contributors
# Copyright (c) 2013-2018 Rapptz, ThePhD, and contributors
#
# Permission is hereby granted, free of charge, to any person obtaining a copy of
# this software and associated documentation files (the "Software"), to deal in

View File

@ -3,7 +3,7 @@
# # # # sol2
# The MIT License (MIT)
#
# Copyright (c) 2013-2017 Rapptz, ThePhD, and contributors
# Copyright (c) 2013-2018 Rapptz, ThePhD, and contributors
#
# Permission is hereby granted, free of charge, to any person obtaining a copy of
# this software and associated documentation files (the "Software"), to deal in

View File

@ -3,7 +3,7 @@
# # # # sol2
# The MIT License (MIT)
#
# Copyright (c) 2013-2017 Rapptz, ThePhD, and contributors
# Copyright (c) 2013-2018 Rapptz, ThePhD, and contributors
#
# Permission is hereby granted, free of charge, to any person obtaining a copy of
# this software and associated documentation files (the "Software"), to deal in

View File

@ -3,7 +3,7 @@
# # # # sol2
# The MIT License (MIT)
#
# Copyright (c) 2013-2017 Rapptz, ThePhD, and contributors
# Copyright (c) 2013-2018 Rapptz, ThePhD, and contributors
#
# Permission is hereby granted, free of charge, to any person obtaining a copy of
# this software and associated documentation files (the "Software"), to deal in

View File

@ -3,7 +3,7 @@
# # # # sol2
# The MIT License (MIT)
#
# Copyright (c) 2013-2017 Rapptz, ThePhD, and contributors
# Copyright (c) 2013-2018 Rapptz, ThePhD, and contributors
#
# Permission is hereby granted, free of charge, to any person obtaining a copy of
# this software and associated documentation files (the "Software"), to deal in

View File

@ -3,7 +3,7 @@
# # # # sol2
# The MIT License (MIT)
#
# Copyright (c) 2013-2017 Rapptz, ThePhD, and contributors
# Copyright (c) 2013-2018 Rapptz, ThePhD, and contributors
#
# Permission is hereby granted, free of charge, to any person obtaining a copy of
# this software and associated documentation files (the "Software"), to deal in

View File

@ -3,7 +3,7 @@
# # # # sol2
# The MIT License (MIT)
#
# Copyright (c) 2013-2017 Rapptz, ThePhD, and contributors
# Copyright (c) 2013-2018 Rapptz, ThePhD, and contributors
#
# Permission is hereby granted, free of charge, to any person obtaining a copy of
# this software and associated documentation files (the "Software"), to deal in