ThePhD 94c287810f It took a lott of work, but we finally have the right rankings for operator[] to work as intended with as minimal room for screwups as possible. ... This should enable operator[] to work in all cases that it is to be expected, thanks to a lot of explicit conversions and some basic overload resolution ranking tricks (e.g., making some conversions a template). We also need to remember that GCC expects `. template (function name)` in generic code, as it can parse things in a really dumb and silly manner.		2013-12-21 22:00:28 -05:00
..
error.hpp	Initial commit	2013-11-25 04:56:27 -05:00
function.hpp	Fixed a bug with the return order and added tests to make sure it works.	2013-12-15 22:09:06 -05:00
lua_function.hpp	Fixed a bug with the return order and added tests to make sure it works.	2013-12-15 22:09:06 -05:00
object.hpp	Add operator== and operator!= support for sol::object and nil	2013-12-14 00:28:14 -05:00
proxy.hpp	It took a lott of work, but we finally have the right rankings for operator[] to work as intended with as minimal room for screwups as possible.	2013-12-21 22:00:28 -05:00
reference.hpp	Removed uses of constexpr for MSVC 2013	2013-11-25 05:20:14 -05:00
stack.hpp	Squashing those GCC warnings.	2013-12-15 22:14:56 -05:00
state.hpp	operator[] support~	2013-12-21 19:30:30 -05:00
table.hpp	operator[] support~	2013-12-21 19:30:30 -05:00
traits.hpp	I wish C++ didn't demand that functions have to appear before each other in lexographic order. =/	2013-12-21 19:39:51 -05:00
tuple.hpp	New test cases for the order of returns. Apparently, its screwing up between both lua and C++. Have to test thoroughly. Changes currently are half-working.	2013-12-15 16:27:20 -05:00
types.hpp	operator!= for nil_t	2013-12-14 20:16:28 -05:00