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)
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
Refactoring on function_types.hpp performed to slim down some of the calls: could use more refactoring
Drastically simplified userdata's binding capabilities: constructor supports both `:` and `.` syntax (but member functions DO NOT).
All tests are passing
Added pop() function to `reference`
`stack.hpp` now has many more functions to properly handle user data
`types.hpp` now has `userdata_t` and `lightuserdata_t` to faciliate `stack`'s `pop` and `push` operations
Class binding functionality built into `table` and `state`, as well as placed in `userdata` class in `userdata.hpp`
demangling detail now present for clang, gcc, and MSVC (somewhat for MSVC)
Constructor arity still needs to be handled for `userdata<T>`
tests updated and passing
But! I left it on the `sol::function` type, because it's necessary to discard returns. The .call is still there, though, just incase you need it. <3
reverse_indices_builder is also there, to make sure we can push and pop without the lua api taking our types and breaking them for the std::tuple returns.
All is at it should be~
STATEFUL FUNCTIONS!
Any stateful function now works and is properly cleaned up, thanks to some additional metatables that are associated with the function values.
This lays the ground work for class bindings, but that's a far off dream. For now, table retrieval and `operator[]` is what's for dinner.
Member functions now work as well for set_function. If performance of `new`ing a type ever becomes too large, we can create a custom allocator for the std::shared_ptr's of the types. We can also up-front allocate for the unordered_map as well.
It'll be up to @Rapptz's to make further changes to make sure GCC compiles, but the core of the functionality is there and my work is essentially done.
Class bindings are up next, but really I don't want to even touch those. :c
