scopterectus
WarCraft 3

Hashtable

Добавлен
Обязательно ли очищать хеш-таблицу через FlushChildHashtable(...)? Смотрел на сайтах wc3c.net, hiveworkshop.com разные наработки и нигде не увидел данную функцию, в то время как на этом сайте её всё же используют.

Принятый ответ

Говоря прямо о вопросе треда, замечу, что FlushChildHashtable стоит применять перед сохранением данных в хэш-таблицу при условии, что в конкретной ячейке таблицы гипотетически что-то может находиться (i.e. данные в неё кладутся БЕЗ использования GetHandleId).
бояться утечек нечего
Просто в качестве примера: я где-то встречал огромную систему динамического изменения текстур террейна посредством уберсплатов, которая при определённых условиях с достаточно большой скоростью выпиливала старые и создавала новые; в этой системе уберсплаты не утекали, но, случись такое, выделенные 2 гига оперативы кончились бы относительно быстро.
5 июл 2017
  • Размещен: 05.07.2017 11:11:22
  • Создан: 05.07.2017 11:11:22
  • Обновлен: 05.07.2017 11:11:22
2 135
0
19
7 лет назад
0
Похожие вопросы:
  1. как очистить от hashtable конкретный хэндл?
ответ
Кет:
Если имеется в виду очистить по первому ключу, то это FlushChildHashtable(hashtable, parentKey).
Если очистить по двум ключам, то можно просто записать в эту ячейку null.
По второму вопросу — конечно, можно, храни и загружай когда хочешь -_-
  1. Hashtable
ответ
GetLocalPlayer:
Зависит от прокладки между стулом и клавиатурой. На вкус и цвет, как говорится.
  1. Hashtables or MUI
ответ
quq_CCCP:
Для спеллов достаточно хештаблицы, массивы самое то для всяких систем перемещения, молний, очень часто повторяющихся операций с большими числом объектов....
Часто системы идут уже с собственным системами хранения данных, timer utils юзает свой атач на таймер или хештаблицу, ну и так далее.
Поиск по всем ресурсам на сайте
0
32
7 лет назад
0
ScopteRectuS, нужно если вы не собрались использовать эту ячейку еще раз.
Там где единожды записанные данные используются все время до конца игры нет нужды очищать таблицу, ну а так где 1 раз за всю игру, разумеется стоит очищять.
Темболее сейчас часто используют наработки вроде TimerUtils и структур vJass, а там записть только 1 целого числа и удаление его RemoveSavedInteger (или как то так, я уже и забыл)
0
21
7 лет назад
Отредактирован scopterectus
0
quq_CCCP, Понял, а если в ячейке хранится тип int, real, bool, string, texttag их же можно не удалять?
а где хранится тип handle, то обязательно удалять? иначе будет утечка?
0
28
7 лет назад
Отредактирован nvc123
0
ScopteRectuS, texttag тоже является handle
0
21
7 лет назад
0
nvc123, DracoLich писал обратное, и его можно создавать локально и это не вызовет десинк.
0
30
7 лет назад
Отредактирован Clamp
0
ScopteRectuS, нельзя создавать локально экземпляры тех объектов, состояние которых так или иначе подлежит синхронизации между игроками (при этом у синхронизируемых объектов зачастую есть несинхронизируемые характеристики состояния).
Тем не менее, возможность создавать что-то локально без приведения к десинхронизации никак не говорит о том, что такие объекты не могут вызывать т.н. "утечек".
Относительно texttag стоит заметить, что это не текст, а расположеный в игровом пространстве объект, этот текст выводящий. Сам текст, являющийся string чистить бессмысленно, за деталями - в статьи на сайте (с учётом реализации таблицы строк в JASS) или в википедии (для более общих или иных частных случаев).
Да и в целом советую почитать про то, что такое хеш-таблица.
0
21
7 лет назад
0
Clamp,
DracoL1ch:
Для продвинутых:
тексттаги не являются настоящими агентами и существуют на компе отдельно от прочего, как и молнии, например. их можно создавать в локальном коде, их не нужно нуллить.
https://xgm.guru/p/100/192427
0
16
7 лет назад
0
каждый объект агент, каждый хендл агент, но не каждый хендл или агент обязаны быть синхронными. из определения ничего не узнать, просто берешь хендл любого созданного тобой объекта. Если он меньше 1000 - это асинхронный объект
0
30
7 лет назад
Отредактирован Clamp
0
ScopteRectuS, как твой ответ (вернее, ответ DracoL1ch) входит в хоть какую-нибудь конфронтацию с тем, что я описал в сообщении выше? В чём была цель подобного цитирования, если оно не привнесло в тред вообще ничего конструктивного, являясь уточнением уже описанного конструктива?
DracoL1ch, емнип, с тексттагами можно было где-то накосячить и таки лишиться активных ссылок на уже существующие (глобально или локально - не так важно) тексттаги без указанного лайфспана => концептуально они утечны, и практически это зависит исключительно от использования.
0
16
7 лет назад
0
локальные объекты протекать могут, конечно, но их упустить сложнее. текст таги имеют длительность жизни, которая их корректно стирает. у молний и уберсплатов лимита я не знаю, есть ли он вообще или нет. а если лимита нет, то и бояться утечек нечего
0
30
7 лет назад
Отредактирован Clamp
0
Говоря прямо о вопросе треда, замечу, что FlushChildHashtable стоит применять перед сохранением данных в хэш-таблицу при условии, что в конкретной ячейке таблицы гипотетически что-то может находиться (i.e. данные в неё кладутся БЕЗ использования GetHandleId).
бояться утечек нечего
Просто в качестве примера: я где-то встречал огромную систему динамического изменения текстур террейна посредством уберсплатов, которая при определённых условиях с достаточно большой скоростью выпиливала старые и создавала новые; в этой системе уберсплаты не утекали, но, случись такое, выделенные 2 гига оперативы кончились бы относительно быстро.
Принятый ответ
0
16
7 лет назад
0
утечка - это 4 байта. сколько таких надо, чтобы заполнить зхотя бы гиг памяти? вот неразрушенный объект - другой вопрос
0
30
7 лет назад
Отредактирован Clamp
0
DracoL1ch, уберсплат - тоже объект, пусть и лёгкий. Течь же по-разному может, где ссылка, а где и сам экземпляр.
0
32
7 лет назад
0
DracoL1ch, смотря сколько их плодится, видел карту по 9000 в минуту+ еще 100500 обьектов.
Чтобы оставить комментарий, пожалуйста, войдите на сайт.