ENIGMA Forums
Outsourcing saves money => Programming Help => Topic started by: sorlok_reaves on October 07, 2014, 08:16:59 pm
-
Why do vars initialize with placement new in ENIGMA?
-
Can you show me a code example sorlok? I am a tad confused by what you mean.
-
In var4_lua.cpp:
void var::initialize() {
new(&values) vararray;
}
void var::cleanup() {
as_lua(values) . ~vararray();
}
-
Oh wow, I am not sure you'll have to ask Josh about that one. I'll forward this to him.
-
Yeah, I never really enjoy dealing with placement new. :P
-
When I wrote var, I had the sense to want to keep the matrix kernel modular, but lacked the sense to do it right. It uses placement new so that the main var class doesn't have to know anything about the type it's storing, which is itself just a pointer. You could easily refactor it so that the lua_table just works with the values data pointer directly, instead of pretending to own it. At this point, I don't even really care if you want to just move the lua_table code into var. If you want to do that refactoring, feel freeāit might even speed up var arithmetic because the compiler will be more confident in its optimizations.
-
I'll give it a shot. I'm assuming the lua_table<lua_table<variant>> construct is used for 2-D arrays. Does that actually work right internally? (I have received mixed information on whether or not arrays "work" in ENIGMA.)
-
The arrays problem in ENIGMA is that variables of type var, when accessed using [], must be encoded using (), because otherwise 2-D access using commas is not supported. Basically, [snip=edl]my_var[1,2][/snip] goes in, [snip=cpp]my_var(1,2)[/snip] comes out. ENIGMA's current type coercion is woefully inadequate, and as a consequence, this ends up happening for all arrays. So only var arrays work. A quick band-aid on this is to only make that replacement when a comma is detected outside of parentheses inside the brackets.
The lua_table implementation is fine. All it does is keep a dense portion and a sparse portion of an array of whatever object type you give it. It's pretty inefficient for one-dimensional access... I should do something about it.
-
Thanks for the description; I think I get it now.