Добавлен Cancel
Что лучше, надёжнее и быстрее?
Работать с группами юнитов: при их добавлениии, проверки наличия, удалении и т. д.
Может, в каких-то ситуациях лучше работать с группами, а в каких-то - с таблицами?
Или создавать структуры, и работать с ними?
Или создавать структуры, и работать с ними?
Если кто-то проводил тестирование в разных ситуациях и/или находил подводные камни двух подходов - поделитесь, пожалуйста.
Интересно знать про рабготы с огромными данными, если в проекте огромное количество групп(или таблиц), в каждой может быть много юнитов, проверки на наличие юнитов в списках происходят постоянно, постоянно происходит добавление и удаление юнитов из списков.
А-ля:
units = {}
table.insert( units, unit )
function isUnitInTable(table, unit)
for k, v in pairs(table) do
if v == unit then return true end
end
return false
end
if isUnitInTable( units, unit ) then
--это выполнится
else
--а это не выполнится
end
Принятый ответ
Hate:
сортированный список
Сортированный не есть упорядоченный. Перед тем как токсичить без причины стоит хотя бы с терминологией ознакомится.
те более если использовать пейрсы как в вашем примере, это путь к десинкам
pairs - это просто функция, которая возвращает функцию next, переданную таблицу и nil. Если у таблицы есть метаметод __pairs, то вызывается он. Таким образом, добавляется метаметод и никаких десинков нет.
отссылая в гугл
Он отослал не в гугл, а на страницу вики от юзеров луа. Но это всё же такой себе источник. И как я уже сказал, pairs вообще не при делах. Всё дело в функции next. Цитата из официальной документации Lua 5.3:
Allows a program to traverse all fields of a table. Its first argument is a table and its second argument is an index in this table. next returns the next index of the table and its associated value. When called with nil as its second argument, next returns an initial index and its associated value. When called with the last index, or with nil in an empty table, next returns nil. If the second argument is absent, then it is interpreted as nil. In particular, you can use next(t) to check whether a table is empty.The order in which the indices are enumerated is not specified, even for numeric indices. (To traverse a table in numerical order, use a numerical for.)The behavior of next is undefined if, during the traversal, you assign any value to a non-existent field in the table. You may however modify existing fields. In particular, you may clear existing fields.
Таким образом, порядок может быть идентичен на разных машинах, а может быть и не идентичен. Поэтому изначальное утверждение Hate правдиво:
что на одном компьютере будет A, B, C а на втором C, B, A
Что касается самого вопроса. Удобство таблиц в том, что их не надо удалять функцией, но нужно реализовать уникальность юнитов. На HIVE есть готовая библиотека, которая включает в себя переписывание нативок для групп юнитов, точек, ректов и групп игроков на таблицы. Краткое описание библиотеки от автора, Bribe:
Most recently, I've revamped the old GUI Fixer Collection to a much more powerful tool: Lua-Infused GUI. Since GUI variables don't actually require strict type assignment when compiled into Lua, I was able to change Locations, Rects, Unit Groups and Player Groups into Lua tables, allowing them to consume an order of magnitude less RAM and be automatically cleaned up by Lua's garbage collector.
`
ОЖИДАНИЕ РЕКЛАМЫ...
Чтобы оставить комментарий, пожалуйста, войдите на сайт.
Отредактирован Cancel
На всех устройствах порядок будет одним и тем же, просто не отсортированным.
Для тебя это слишком сложная концепция?
Отредактирован Hate
без приведённых пруфов всё равно придётся набирать людей и тестировать.
если бы я не слушал, я бы сказал что ты всё врёшь, а я лишь запросил подтверждения, и тебя это выбесило (видимо, привык, что тебе все на слово верят)
Если у тебя проблемы с агрессией, прошу обходить меня стороной.
упорядочивание элементов происходит не по индексам, а по байтовым представлениям (это нормальная история для мапов), поэтому с точки зрения человека упорядоченность является хаотичной.
Но хаотичная упорядоченность одних и тех же элементов будет всегда одинаковой, сколько бы раз ты не запускал скрипт.
Ты заранее не сможешь сказать в каком порядке будут располагаться элементы, но многократное пересоздание мапов с одними и теми же элементами в итоге приведёт к идентичной последовательности пар.
Это по стандарту LUA и C.
Я о таких подводных камнях в рамках варика не знаю, спросил у тебя - знаешь ли ты про них, на что ты высокомерно заявил, что нужно изучать таблицы. Ну так если брать вне варкрафтского контекста, то я тебе по стандарту языка могу сказать, что последовательность при одинаковом контексте будет одинаковой.
Если у тебя нет экспертизы - так и скажи: "я не проверял, но мне кажется что...", а не бросайся словами о чужой глупости.
Отрефлексируй это.
Возможно, я не проверял (пока не с кем проверить), и нюансов варкрафта знаю явно меньше, чем большинство здешних пользователей.
Так где же может возникнутьошибка? На этапе объявления таблицы; добавления в неё элемента?
Отредактирован Cancel
Inside a pairs loop, it's safe to reassign existing keys or remove them (by assigning nil to them), but not to add new keys (that had a nil value previously).
Знаешь почему?
Потому что это для тебя ключи беспорядочны, а для системы они упорядочены в байтовом представлении, это нужно для того, чтобы быстрее осуществлялся поиск ключей системой.