You're saying the slice offset would be stored in the userdata itself?
This would imply that setting a slice would mutate the userdata object?
If not, your slice still needs to create an extra object,
in which case, how is this better than the uservalue option?
i.e.
void makeslice(lua_State *L, int idx, ssize_t offset) {
idx = lua_absindex(L, idx);
ssize_t* slice = lua_newuserdata(L, sizeof(ssize_t));
*slice = offset;
lua_pushvalue(L, idx);
lua_setuservalue(L, -2);
}
void* getslice(lua_State *L, int idx) {
ssize_t offset = *(ssize_t*)lua_touserdata(L, idx);
void* udata = lua_touserdata(L, lua_getuservalue(L, idx));
return udata+offset;
}
I don't want to create an extra object, because it's more expensive. and we should cache all the extra objects because the extra object with the same slice offset should not be create more than once, if we use them as a table key .
I'm not sure how this would work?
You need 64bits to store a userdata address on a 64 bit architecture.
We can create the array in global state to store all the userdata pointer, and use the index (handle) in lua value, 32bit index is enough. and lua_touserdata can be also return the pointer by lookup the array with index.
> Storing C/C++ objects in GUI or 3d engines could be more simple : OBJECT.X
> and OBJECT.X.Y can be the same userdata with OBJECT without creating new
> userdata, only the slice is different.
But you would still need a different object.
We don't need a different object, an associated integer is enough. In the metamethod, we can get the associated integer (It can be offset or a index number) first, and then convert it to the sub object's real address with a map (in C) in root object.
This can be reduce the number of lua userdata, we don't need create large number of userdata for C objects , many sub objects may only access once (especially in 3d engine bindings), but we should also create an userdata for them now, and should do more for collecting them correctly.
