Язык Lua. Общие вопросы программирования

[Dennis_Chikin 3 658]

С чего начинать и где взять.

 

Установка Lua:
http://www.amk-team.ru/forum/index.php?showtopic=11584&p=629106

 

Руководство «Программирование на языке Lua», третье издание:
http://www.amk-team.ru/forum/index.php?showtopic=11584&p=905308

Изменено 2 Марта 2015 пользователем Kirgudu

[RayTwitty 492]

Необходимо вызвать функцию для объекта, сама функция сохранена в виде строки, например:

-- обычный вызов
actor:name()

-- то что я хочу
func = "name"
actor:<<func>>()

либо как-то сохранять ссылку на метод без использования строки... Пока наколхозил такое:

function call_string(obj, method, ...)
	local args = {...}
	return loadstring("return function(obj, args) return obj:"..method.."(unpack(args)) end")()(obj, args)
end

возможно ли сделать лучше? Изменено 30 Января 2016 пользователем RayTwitty

[Struck 61]

@RayTwitty, обычный синтаксический сахар не покатит?

local function call_string(obj, method, ...) return obj[method](obj, ...) end

[Charsi 440]

function call_string(obj, method, ...)

return obj[method](obj, ...)

end

[RayTwitty 492]

t = {["A"] = "a", ["B"] = "b", ["C"] = "c", ["D"] = "d"}
for k, v in pairs(t) do
print(k.." "..v)
end

Перебор элементов идет в рандомном порядке, отчего так? Юзать ipairs очень неудобно, так как работает похоже только с числовыми ключами:

t = {[1] = "a", [2] = "b", [3] = "c", [4] = "d"}
for i, v in ipairs(t) do
print(v)
end

[Desertir 202]

@RayTwitty, читаем доки. next, через который работает pairs, не гарантирует никакого порядка. Как в память попадет, скорее всего, такой и будет порядок.

Встречный вопрос, даже 2. Зачем нужен порядок? И чем не угодил ipairs?

[RayTwitty 492]

next, через который работает pairs, не гарантирует никакого порядка.

Ну это-то я читал, вопрос был больше о том, почему так странно реализовано?..

 

Зачем нужен порядок? И чем не угодил ipairs?

На практике у меня там несколько вложенных таблиц, поэтому и порядок обработки важен. Если делать через ipairs, структура таблиц будет крайне убога. Изменено 31 Января 2016 пользователем RayTwitty

[dsh 3 824]

@RayTwitty, общее правило, во всех языках, которые я знаю, от хэша, т.е. от структуры, к элементам которой мы обращаемся по произвольному ключу, опрометчиво ожидать порядка в возвращаемых ключах. Как решать этот вопрос, зависит от тоей задачи, которую никто не знает, кроме тебя. Может тебя надо получить список ключей и отсортировать их предварительно. А может тебе какая-то другая структура данных нужна. Я в своей практике не встречал ситуаций, вот что бы прямо кровь из носу, но хэш мне должен возвращать ключи в порядке их записи. Всегда есть варианты.

[RayTwitty 492]

Может тебя надо получить список ключей и отсортировать их предварительно. А может тебе какая-то другая структура данных нужна.

Причем тут сортировка и другие структуры данных? Я вообще-то уже всё сказал и показал - какая таблица и что надо сделать - последовательно перебрать ключи A,B,C,D в этой таблице.

 

upd:

t = {[1] = {["A"] = "a"}, [2] = {["B"] = "b"}, [3] = {["C"] = "c"}, [4] = {["D"] = "d"}}
for i, tabl in ipairs(t) do
for k, v in pairs(tabl) do
print(k.." "..v)
end
end

Если только так, но выглядит ужасно. Изменено 31 Января 2016 пользователем RayTwitty

[Struck 61]

@RayTwitty, пробуй:
 

function my_pairs (t)
local a = {}
for n in pairs(t) do a[#a + 1] = n end
table.sort(a)
local i = 0
return function()
i = i + 1
return a[i], t[a[i]]
end
end

local ex = {["b"] = 1, ["e"] = 2, ["c"] = 3}

for name in my_pairs(ex) do
print(name)
end

[Charsi 440]

Можно написать свой итератор, который создает массив ключей, упорядочивает его нужным образом и выдает при вызове ключ из этого массива и его значение.

local t = {["A"] = "a", ["B"] = "b", ["C"] = "c", ["D"] = "d"}

function asc_iter(t)
	local pos = 0
	local keys = {}
	for k in pairs(t) do table.insert(keys, k) end
	table.sort(keys)

	return function()
		pos = pos + 1
		return keys[pos], t[keys[pos]]
	end
end

for k, v in asc_iter(t) do
	print(k, v)
end

 

 

Изменено 31 Января 2016 пользователем Charsi

[RayTwitty 492]

@Charsi, с A,B,C,D конечно работает, но название ключей в реальности могут быть какие угодно, поэтому сортировка может изменить порядок.

 

Детальный разбор вопроса показал, что сделать нормально никак нельзя. Если бы ключ был объектом или таблицей, в котором лежал бы его номер, тогда наверно и pairs работал нормально, а ipairs вообще стал не нужен:

local t = {sequence = {"first", "123", "qwerty"}, ["first"] = 2332, ["123"] = "rutr", ["qwerty"] = 999}
for i, v in ipairs(t.sequence) do
	print(v, t[v])
end

Изменено 31 Января 2016 пользователем RayTwitty

[Charsi 440]

Сортировка как раз и устанавливает порядок доступа. В хеш-массиве никакой упорядоченности быть не может. Если ключ это объект или таблица, то в table.sort вторым аргументом можно передать функцию, реализующую упорядочивание таких ключей.

[RayTwitty 492]

Если ключ это объект или таблица, то в table.sort вторым аргументом можно передать функцию, реализующую упорядочивание таких ключей.

Да даже если ключи простые строки - не упорядочишь ты их так, как было изначально, если конечно не будешь парсить документ и смотреть какой ключ за каким шел. Номера ключей надо где-то хранить в любом случае. Изменено 31 Января 2016 пользователем RayTwitty

[Kondr48 314]

Такой вопрос, как скинуть имеющуюся таблицу в конфиг файл? Понятно, что довольно медленно может оказаться, поэтому лучше это дело впихнуть куда нибудь во время загрузки уровня?
p.s shoc 1.0007 (rev.188)

Изменено 31 Января 2016 пользователем Kondr48

[Graff46 598]

Какие есть методы копирования файлов в луа на стандартной библиотеке?

[Malandrinus 615]

 

 

вопрос был больше о том, почему так странно реализовано?

Потому что хэш-таблицы. Сама природа хэша такова, что это в сущности случайное число, а значит и ожидать упорядоченности невозможно. Почему именно хэш? Потому что пока не придумали ничего лучшего с почти линейным временем доступа по произвольному ключу. Например в бинарных деревьях (которые как раз внутри отсортированы) время доступа измеряется логарифмом от количества. При этом подразумевают одинаковый тип ключей и кроме того требуют перебалансировки при добавлении/удалении элементов.

 

 

Ещё в качестве комментария ко всем. Почему-то почти все говорят сходу про таблицы Lua - хэш-таблицы. Это не вполне корректно, поскольку по определению таблицы в Lua - это ассоциативные массивы или по-простому с доступом по ключу. Описание языка Lua никак не определяет способ реализации. Реализация таких массивов может быть весьма разная, и хэш-таблицы - это только один из способов.

[Charsi 440]

@Graff46, можно так: os.execute("copy path_from path_to").

[Graff46 598]

 

 

os.execute

Это не подходит (сворачивает игру). Надобность в копировании у меня все равно отпала. Скажу что на форуме lua.ru я нашёл разные примеры. Алгоритм заключался в том что файл открывался на чтение, считывался, потом "записывался" в другом месте.

[TIGER_VLAD 361]

 

 

Алгоритм заключался в том что файл открывался на чтение, считывался, потом "записывался" в другом месте.

Можешь код показать?

[Graff46 598]

@TIGER_VLAD, Посмотрите из первоисточника.