Здравствуйте,
В рамках улучшения моей статьи о JASS провёл небольшое исследование о типах данных в JASS и их структуре. В своём текущем виде типы не распределены должным образом, что затрудняет понимание. Нужно подтверждение или опровержение того, верно ли я понял, что собой представляет тот или иной тип.
Итак...
Текста много, спрятано под кат
  • integer, boolean: Прямые наследники типа __int32 языка программирования Си. Обладают теми же свойствами, что и этот тип.
  • real: Прямой наследник типа float языка программирования Си.
  • string: Изначально задаётся как массив типа char до 1023 байт, который затем отсылается на добавление в хеш-таблицу(Хеш-таблица), где содержатся иные массивы типа char. Скорее всего, при работе с этим типом также используется ассоциативный массив, который сначала хэширует строку (функция StringHash в JASS), потом этот хэш строки (число) переводится в строку и становится индексом ассоциативного массива. Если по этому адресу в массиве нет никакой ячейки в хэш-таблице, то в тип string записывается ссылка на новую ячейку, куда заносится строка. Если ячейка обнаруживается, то заносится адрес существующей ячейки. В дальнейшем тип string действует как указатель, но не на адрес в памяти, а на адрес в хэш-таблице. При этом конкатенация строки, выделение из неё подстроки или любая иная операция с ней повторяет операцию с отсылкой на добавление в хэш-таблицу и прогон через ассоциативный массив.
  • agent: Просто одна большая группа данных, которую возможно сохранить в hashtable. Скорее всего, это указатель, который указывает на указатель, который указывает на указатель (:[)... (например, agent ссылается на определённый widget, а widget ссылается на определённого unit, который ссылается на таблицу в памяти со всеми свойствами боевой единицы).
  • Везде, где я писал "ссылка на идентификатор": На самом деле, не что иное, как битовые поля. gamestate, igamestate и fgamestate, возможно, тоже реализованы через битовые поля.
  • group, force, dialog, multiboard, leaderboard (возможно): Связные списки, наверняка однонаправленные. group содержит список объектов типа unit, force содержит список объектов типа player, dialog содержит список объектов типа button, multiboard содержит список объектов типа multiboarditem, leaderboard содержит списки объектов player и integer.
  • Прочее: Просто таблицы со свойствами.
Заранее благодарен за пояснение.
С уважением,
Singularity, 03.07.2017
2
32
7 лет назад
2
Агент это не тип как таковой, это все хендлы. Агент введен для хештаблицы, чтобы меньше морочится с сохранением и загрузкой данных.
Раньше была фишка fogstate exploit
call SaveFogStateHandle( hashtable, 0, 0, ConvertFogState( GetHandleId( любой хендл до fogstate ) )
return LoadUnitHandle( hashtable, 0, 0 )
Вот такой код позволяет не морочится и сохранить почти любой ссылочны тип, а выгрузить получится только такой какой он есть. Т.е у нас есть одна универсальная функция под записть и множество под чтение конкретного типа, агент введен для этого насколько я помню. Подробнее о наследовании типов можно посмотреть тут.
Про диалог и мультиборд бред, это хендлы самих обьектов, кнопки и текст вовсе отдельные обьекты, такие как dialog button и multiboarditem.
0
13
7 лет назад
0
quq_CCCP, это какая-то внутренняя ошибка позволяет так сохранять любой handle? Просто раньше о такой фиче не знал)
0
32
7 лет назад
Отредактирован quq_CCCP
0
Пушистый:
quq_CCCP, это какая-то внутренняя ошибка позволяет так сохранять любой handle? Просто раньше о такой фиче не знал)
На самом деле все handle типы это одинаковые ссылки, в таблице хендлов и хранятся все эти типы, ну а в функциях которые требуют эти хендлы уже и ведется проверки на то что есть что. Другими словами и локейшин и юнит можно сделать целым числом и сохранить в хт, но сделать из локейшина юнита или наоборот не получится.
Fogstate exploit это один из многих не досмотров близзардов, как и ретурн баг и прочие ошибки.
Чтобы оставить комментарий, пожалуйста, войдите на сайт.