Формат данных на C++, который не боится рефакторинга

[sergey2212]

Классный пример. Практичный. Если формат выживает на графах — он переживёт почти что угодно.

[nin-jin]

А почему вы обфусцировали не весь код? Не боитесь, что его украдут?

[Adler3D]

я исхожу из того, что вероятность найти полезных людей через открытую публикацию выше, чем риск пострадать от тех, кто просто хочет что-то утащить на халяву.

[nin-jin]

А как вы решили что обфусцировать, а что - нет?

[Adler3D]

вроде ничего специально не обфусцировал и просто выложил почти все свои исходники почти всех проектов(уже много лет назад), сейчас просто решил написать к ним статьи/документацию и пошарить на публику, вдруг какая-то толковая аудитория увидит/оценит/присоединится/поможет.

[HiItsYuri]

Кодстайл интересный, конечно. Сводит на нет полезность сниппетов.

[alexdmy]

gcc -E file.cpp в помощь

[domix32]

Теперь идея понятна. Хотя подход я бы назвал сомнительным. В кооперативе подобными расширениями обычно не занимаются - из-за скорости итерирования, а в соло проще простенькие конвертер написать и также расширять немного кода по мере разрастания структур данных - месиво из макросов поддерживать сложнее, чем пару функций чтения/записи, а мигрировать данные с v0 до v200 кажется нереалистичным, чтобы иметь какое-то применение.

[xakepp35]

Пример неудачный. Сплошные маркосы слабочитаемые дефайны, либо код вида q.w.e.r.t.y*=z.x.c.v.b; рекомендую в следующий раз перед постом просить llm отрефакторить ваш код в целях повышения наглядности и читаемости. Это улучшит качество оьучающего материала. Также можно выбрать более современный актуальный язык, хотя бы с поддержкой подсветки синтаксиса.. тот же раст вон позволяет писать все те же игры и там есть тоже своя философия, но и включена подсветка синтаксиса и проверка типов компилятором.

[ZODIACwv]

можете объяснить, я джун вот, пусть мейню шарп, но основной смысл меняться не должен, вот как у меня устроены сейвы: есть 1 менеджер загрузки сохранения и менеджер проекта, последний вызывает лоад и передает ссылки на созданные десериализацией объекты куда надо, весь код меняет данные прям по этим ссылкам, а потом менеджер проекта просто вызывает сериализацию в жесон для тех же обьектов и прекрасно все сохраняет, таким образом, если я добавляю поля, то десериализатор жесона автоматически пихнет все по именам полей куда надо, а остальные значения оставит по умолчанию, а значит, что я легко могу добавлять любые новые поля, которые сами обновят сейв при ближайшем же вызове сохранения, в чем проблема такого подхода?

[Adler3D]

не знаком с шарпом, но судя по вашему описанию у вас будет раздутый(из-за постоянного перечисления одних и тех же имён полей объектов) формат файл сохранения по сравнению с моим бинарным. а ещё json-формат должен проигрывать по скорости загрузки/сохранения.