Tables, null, nil, AAH

[ThePhD]

Observe.

#define SOL_CHECK_ARGUMENTS

#include <sol.hpp>
#include <vector>
#include <map>
#include <cassert>
#include <iostream>

int main(int argc, char** argv) {
	struct test {
		int a = 20;
	};
	
	sol::state lua;

	test v;
	lua.create_named_table("tests",
		1, &v,
		2, nullptr,
		3, &v
	);

	lua["tests_2"] = std::vector<test*>( { &v, nullptr, &v } );

	lua.set_function("f", [](sol::as_table_t<std::vector<test*>> src) {
		std::vector<test*>& tests = src.source;
		std::cout << "f: ";
		for (const auto& t : tests) {
			std::cout << static_cast<void const*>(&t) << " ";
		}
		std::cout << std::endl;
	});

	lua.set_function("g", [](std::vector<test*>& tests) {
		std::cout << "g: ";
		for (const auto& t : tests) {
			std::cout << static_cast<void const*>(&t) << " ";
		}
		std::cout << std::endl;
	});
	lua.script(R"(
f(tests)
f(tests_2)
-- g(tests) -- this line would crash, is expected to
g(tests_2)
	)");
	return 0;
}

Results:

f: 000000846FCFF6E4
f: 000000846FCFF6E4
g: 000000846FCFF6E4 0000000000000000 000000846FCFF6E4

Only a problem with sol::as_table_t and other table-based operations that depend on what Lua calls a "sequence". Regular userdata-style containers are unaffected by what Lua considers to be a "break" or "hole" in a sequence (Goes from 1 to n, until it encounters a nil value, and has no other key-value pairs besides the upcounting integer ones). Should we do anything about it? One option is making a separate "nullptr" object in Lua. This seems like a non-issue when -- if a person uses "real" containers -- this can't happen and nulls can be embedded just fine...

[ThePhD]

Buh. There's nothing we can really do about this that isn't just a patchjob. People will just have to be careful what they push into Lua and when they stick big fat nullptrs in the middle of pointer vectors?