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] be as ridiculously explicit as possible

Browse Source
This commit is contained in:
ThePhD 2016-09-11 04:49:05 -04:00
parent 5dface25fb
commit a7f43991eb
2 changed files with 3 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
docs/source/api/simple_usertype.rst
View File

@ -12,4 +12,5 @@ This type is no different from :doc:`regular usertype<usertype>`, but with the f
- ``sol::var`` takes the wrapped up type and pushes it directly into that named slot
* Automatic "__index" and "__newindex" handling is not done
- Overriding either of these properties leaves it entirely up to you to handle how you find variables
- This also means *no base class method lookup is done whatsoever*; please specify all base class variables/methods on the class itself
- If you override "__index" or "__newindex", you must perform a raw get on the original table and return a valid function / value if you want it to find the members you already set on the ``simple_usertype``

4
docs/source/api/usertype.rst
View File

@ -210,7 +210,7 @@ Otherwise, the following is used to specify functions to bind on the specific us
* ``"{name}", sol::overloaded( Func1, Func2, ... )``
- Creates an oveloaded member function that discriminates on number of arguments and types.
* ``sol::base_classes, sol::bases<Bases...>``
- Tells a usertype what its base classes are. If you have exceptions turned on, this need not be necessary: if you do not then you need this to have derived-to-base conversions work properly. See :ref:`inheritance<usertype-inheritance>`
- 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
@ -279,7 +279,7 @@ Then, to register the base classes explicitly:
.. warning::
Sol currently attempts to link base class methods and variables with their derived classes with an undocumented, unsupported feature, provided you specify ``sol::base_classes<...>``. Unfortunately, this can come at the cost of prformance, depending on how "far" the base is from the derived class in the bases lookup list. If you do not want to suffer the performance degradation while we iron out the kinks in the implementation (and want it to stay performant forever), please specify all the base methods on the derived class in the method listing you write. In the future, we hope that with reflection we will not have to worry about this.
Specify all base class member variables and member functions to avoid current implementation caveats regarding automatic base member lookup. Sol currently attempts to link base class methods and variables with their derived classes with an undocumented, unsupported feature, provided you specify ``sol::base_classes<...>``. Unfortunately, this can come at the cost of performance, depending on how "far" the base is from the derived class in the bases lookup list. If you do not want to suffer the performance degradation while we iron out the kinks in the implementation (and want it to stay performant forever), please specify all the base methods on the derived class in the method listing you write. In the future, we hope that with reflection we will not have to worry about this.
inheritance + overloading