Сообщение от Mr_F_
я у себя в игре задолбался с динамически создаваемыми объектами, большинство глюков выходило именно из-за них. в результате по максимуму зарезервировал в сцене важные сложные объекты типа всех приезжающих копов, их машин, чтобы они всегда чётко были одни и те же.
у меня трабла значительная была ещё с тем, что переменных просто миллион, каждый нпс в себе содержит добрую сотню их, а завтра я могу добавить ещё какой-нибудь float timeToStopShoutingAtDogsWhoShitUnderTrees, и мне ещё это добавлять в сейв/лоад?! а у каждого нпс с уникальным поведением/диалогами - ещё свои переменные. так что необходимо было мутить универсальную систему, которой не нужно знать ничего более имени класса, руками перебирать я бы просто обосрался.
и вот в С++ думаю разве что кодогенератором сделал на основе существующих хидеров с переменными.
|
тред не читал @ сразу отвечал.
А в чём проблема сериализовать объект путём тупо дампа занимаемой им памяти? Проблемы будут только со значением указателей, все же другие типы переменных должны после обратного действа адекватно восстановиться.
Альтернативное решение - намутить свой менеджер параметров. Как-то надо было реализовать класс, в котором (по мере проработки ТЗ) постоянно удаляли/добавляли кучу логически слабо связанных параметров, поэтому "тупо массив" использовать было неудобно. Что-то типа: объявляется пространство имён
МоиПараметры, а внутри - безымянный enum
enum {AI_FLAG,
AI_PAR1,
BOT_VEL,
//insert new val before this line
PARNUM}
и т.п., таким образом, автоматом регистрируем легко расширяемый набор констант с уникальными кодами (соответствующие индексам). Все допустимые параметры в одном пространстве имён - опечататься нельзя: достаточно сделать квалификацию
МоиПараметры:: и IDE всё подскажет. Количество памяти под параметры вычисляется на этапе компиляции, после определения значения "служебной" константы
МоиПараметры::PARNUM (код очевиден - не буду приводить)
Менеджер, оперирует параметром, зная его код, скрытый от программиста интуитивным именем константы. Включать/исключать пространство имён в классы следует в зависимости от архитектуры и взаимосвязей объектов. Зато массовые операции (запись, загрузка, упаковка, распаковка - которые тоже необходимо было реализовать в моём случае) кодятся просто. Добавляется дополнительная защита от забывчивости с размерами памяти под параметры, и от опечаток в именах, и от сокрытия области видимости, исчезает проблема с "дырками" в массиве в ходе рефакторинга, уходим от конкретных значений индексов и проч.
Внутри менеджера, можно использовать быстрый контейнер (если уместно - даже просто массив), а скорость интерфейса ограничится лишь степенью обеспечиваемой безопасности (меньше проверок - быстрее работает) и "гомогенностью" типов параметров.