Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Objective C++ support #9

Open
rpavlik opened this issue Aug 14, 2013 · 3 comments
Open

Objective C++ support #9

rpavlik opened this issue Aug 14, 2013 · 3 comments

Comments

@rpavlik
Copy link

rpavlik commented Aug 14, 2013

Saw this commit in the network:
wuhao5@7a3bdc5

Objective C/C++ has "nil", so they rename it here to nil_. (the rest of the commit is unrelated test fixing). API breaking if you used nil, but seems prudent. Worth integrating?

@Oberon00
Copy link
Owner

Actually I'm not sure if nil is needed altogether; is there a case where it behaves differently from an uninitialized (i.e. default constructed) object?

@rpavlik
Copy link
Author

rpavlik commented Aug 14, 2013

The docs indicate that it can be used to assign nil to a table element (or presumably any other luabind::object). It seems unused in the source code and tests aside from this.

@Oberon00
Copy link
Owner

A uninitialized object can also be used to assign nil, but only because it ultimately does lua_rawgeti(LUA_REGISTRYINDEX, LUA_NOREF) and there is nothing at LUA_NOREF (-2) in the registry. The Lua Reference Manual states:

The integer keys in the registry are used by the reference mechanism, implemented by the auxiliary library, and by some predefined values. Therefore, integer keys should not be used for other purposes.

So I think one could say that this behaviour is "implicitly documented" in Lua.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants