function result is meant to be transient, and therefore should not be regularly storeable by the user... but there is no way to make a "and you can't have anything but a temporary to this" type, as far as I can tell.
checkargs is now properly propogated through the "call" functions
tests now define SOL_CHECK_ARGUMENTS to make sure
the tests will always check arguments now as well (caught one minor implementation detail missing from that!)
sol::object had a few reference leaks in the way it retrieved values: it now does it properly without leaving the stack at +1 item
sol::stack was drastically cleaned up, with the following key change:
* sol::stack::push now returns an integer of the number of things its pushed (usually 1, but can be more) (Thanks, @PrincessNyanara!)
* sol::stack::call now calls functions flexibly, and getting is done more reliably
* due to the innovation of stack::call and using absolute indices, we no longer have to use reverse_call style programming to deal with lua
* sol::reference::get_type is now const-correct
* sol::state and sol::table now have a cleaned up `get` implementation since it is no longer held back by the ugliness of VC++'s incapability to handle templates
* the name `sol::userdata` now belongs to a type that actually encapsualtes a void* with a pusher/getter than gets a userdata void* value (TODO: give it a template to make it static_cast to that type on get?)
* lightuserdata_t -> light_userdata, upvalue_t -> upvalue as type names (mostly details)
* pushers for various types were updated to return integers
Also a convenience type `sol::ref`, which is just an
alias to `std::reference_wrapper`, to enable easy getting with `lua.get<>`
(we can't use `lua.get<some_type>` because of necessary `Unqualified<T>` use)
now are usable as functions for userdata.
allows free functions and lambdas to provide useful operations, like operator+*-/
and other things which may not be implemented as class members.
userdata now performs lookup based on tables
userdata now has reduced number of vector tables
userdata garbage collection improved
debug.hpp - new header for debugging problems with stack, mostly for internal use
this triggered overhaul of set_function/pusher<function_t>::push(...)
both state and table reflect changes to userdata structure to make it easier to use
tests updated to account for overload resolution
some function-related traits added to make use easier -- cleaned up archaic typenames in function_types.hpp
Account for std::reference_wrapper for objects -- sol now uses copy-by-default (value-semantics) for all functors
updated tests to reflect this
Userdata now properly forwards arguments to constructor
get_call now properly has extra parameters to allow for forwarding items from the first call that are not popped
Added tests to cover new cases
c++ semantics dictate that it's accessed by index, but the tests seem to want to indicate that it should be accessed like a hashmap (or just using basic lua table semantics)
i have no idea how to make this incompatibility work in the new system...
i will ask repo master if he knows anything
`#` == __len
`[key] = value` == __newindex
`key` == __index
are not working properly for some reason, will need to investigate more deeply to find out why
on bright side all tests pass including new tests added (for take/return std::function)
fixed some things forgot to change with addition of upvalue_t for clarity (see previous commit about userdata/lightuserdata vs upvalue)
i want to use an is_function trait to differentiate classes when they get pushed
problem i feel that is_function may capture things not necessarily intended to be function objects
right now it is only qualified by pusher<function_t>
if change is necessary, then it becomes pusher<T, EnableIf<IsFunction<T>>>
a lua upvalue can be lightuserdata, userdata, or anything else that can have its address taken (it's immediately popped of the stack and carted around with function call)
a lightuserdata can only be a pointer (void*)
a regular userdata can be anything, but is stored as void* because of "anything" semantics and C heritage of lua
upvalues deserve to use the `lua_upvalueindex(n)` macro: lightuserdata/userdata does not (must not) go through this process
get turned into getter<T>, matches pusher<T> and uses same semantics as std::allocator and other things used throughout the codebase
-----
userdata has its traits defined outside in new file of userdata to prevent errors when trying to use those typetraits in places before userdata.hpp gets included
userdata was changed to support returning itself via pointers or references.
rework of stack changes semantics based on T&, T*, and T&& (the last one tries to create a new userdata and move in data)
solves problems maybe presented in https://github.com/Rapptz/sol/issues/25
-----
container.hpp is attempt at solving original problem before going on wild tangent with userdata, stack, and get
is going to attempt to use userdata to allow transporation of containers losslessly, perhaps without copying need
-----
found out trying to return a std::function does not work -- not sure what do exactly?
perhaps should push c closure as last thing, but right now it is tied to a key value (code comes from table.hpp and set_function)
will just have to think over how stack arranges itself and learn what to do
by forward-declaring the std::function overload in `stack`, it is able to find the right function to use.
All tests are passing
the ninja file has been tweaked to make it easier to invoke a g++ build on windows
tests added to confirm userdata can be passed into C++ function types
demangle is now named lua_demangle, and the core demangle without any replacements (to fit lua) is just named demangle
Formattings fixes everywhere
Fix for userdata to accept base classes where the derived class uses the name of a base member function to access it (Derived::get_num, where get_num is only implemented in Base::get_num)
VC++ makes this acceptance easy by taking the name as "Derived", but GCC and Clang
