Всех приветствую. Возник такой вопрос. При создании одной занятной системы, связанной с хэш-таблицей, при постоянном использовании функции с конструкцией возникает выделение памяти, доходящее до предела и выбивает вар. Привожу часть кода, который вызывает сомнения:
}elseif GetHandleId(LoadUnitHandle(table,parentKey,childKey) > 0){
	return UNIT_STR
}elseif ..
Пояснения, зачем и как это работает: позволяет определить тип переменной, сохраненной в конкретной ячейке хэш-таблицы (помогает при debag'е), но память все же выделяется, что быть не должно. Как с этим бороться?
P.S.: я знаю, хэш-таблицы - зло, но все же мне нравится их использовать.

MultiboardGetItem создает игровой объект-ячейку, MultiboardReleaseItem разбивает её обратно. Если таблица навсегда. то выгоднее хранить объекты в массиве, чтобы не терять время на постоянные Get-Release + это позволяет в дальнейшем асинхронно менять содержимое ячеек, что невозможно, если использовать функции.
Ну а кто жрет память, моешь с помощью этой тулзы глянуть (может не запускаться, у меня работает) - кинуть в корень варика и запустить при работающей игре
Загруженные файлы
`
ОЖИДАНИЕ РЕКЛАМЫ...
20
Если UNIT_STR не является уникальной генерируемой строкой, то в этом фрагменте кода нечего бояться, поскольку осуществляется только чтение из ХТ. По крайней мере, так подсказывает здравый смысл
13
Diaboliko, строки с типизацией объявлены через дефайн. Может, в этом проблема?
define{
	...
    DESTRUCTABLE_STR = "destructable"
    ITEM_STR = "item"
    UNIT_STR = "unit"
    ABILITY_STR = "ability"
	...
}
28
Пушистый, проблемы не в дефайне
лично меня в твоём коде смущают скобки
а именно отсутствие закрывающей скобки
13
nvc123, просто навел часть из перебора по 40+ типам. Там суть одинакова. Все равно грузит память (пробовал заменить дефайн на константы). Такой перебор нужен, чтобы конкретизировать handle.
32
Ты случаем не плодишь строки?
Тип string в JASS это хендл из таблицы строк, туда попадает все, по осторожнее со строками.
13
quq_CCCP, со строками есть такое. Типы в ячейках транслирую по мультиборду:
MultiboardSetItemValue(mbi,GetSavedValueTypeStrAdv(SYSTEM_HASHTABLE,HashtableUtils_ParentKey,childKey))
Функция, которая в этом действии возвращает строку - название типа после перебора. Если интересно - могу прикрепить карту.
Был вариант выводить числа, но все равно тогда приходится применять I2S, что опять дает строку.
32
Мб из иконок сделать типы раз строками засирается память при юзе твой системы с мультмбордами?
Карту кинь, потом гляну... Мб еще лич заинтересуется.
13
quq_CCCP, вот, извиняюсь за примитивность, конечно. Идея с картинками хороша, нужно будет попробовать.
Загруженные файлы
28
Пушистый, в том коде что ты кидал строки не утекают
они хэшируются как и любые строки
мб ты затираешь значения в таблице?
например сохранил юнита в ячейку 1-1 а потом в эту же ячейку точку
в результате юнит в игре остался а в таблице нет
16
хт не зло, а настоящий дар свыше
у тебя везде MultiboardGetItem, а кто будет MultiboardReleaseItem делать?
13
DracoL1ch, просто раньше таблицы так критиковали, говорили перейти на массивы и структуры. Вот поэтому и пришлось так назвать) А функция release что делает? Удаляет сам объект ячейки? Просто за все время я почти не работал с лидербордами и мультибордами, поэтому для меня это не совсем известная тема.
DracoL1ch, с применением функции вопрос с потреблением памяти решился, но все равно по диспетчеру задач потребление медленно-медленно растет.
16
MultiboardGetItem создает игровой объект-ячейку, MultiboardReleaseItem разбивает её обратно. Если таблица навсегда. то выгоднее хранить объекты в массиве, чтобы не терять время на постоянные Get-Release + это позволяет в дальнейшем асинхронно менять содержимое ячеек, что невозможно, если использовать функции.
Ну а кто жрет память, моешь с помощью этой тулзы глянуть (может не запускаться, у меня работает) - кинуть в корень варика и запустить при работающей игре
Загруженные файлы
Принятый ответ
28
просто раньше таблицы так критиковали, говорили перейти на массивы и структуры.
просто некоторые уникумы используют таблицу там где она нафиг не нужна
либо используют не правильно
ну и в большинстве случаев структуры удобнее чем таблицы
т.к. намного проще сделать missile.getDamage() чем таскать из таблицы данные
особенно если данные потом надо обработать и заново записать в таблицу
особенно весело работать с таблицей когда в качестве индексов выступают не константы/дефайны а магические числа
и потом месяца через 4 вспоминай что там хранилось в ячейке 16-5
16
а в чем принципиальная разнциа будет? можно написать аналогичный интерфейс под таблицы, если так нравится конкретно этот синтаксис.
и нет никаких проблем с индексами, если следовать собственным правилам. В №2 всегда кастер, в №5 всегда уровень, там же булька - есть улучшение или нет, в №17 дамми и т.д.
Чтобы оставить комментарий, пожалуйста, войдите на сайт.