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