Comments 20
Исправить код не составит труда, достаточно заменить вызов memcpy на std::uninitialized_copy:
И вот тут вы погорели! Если открыть документацию к движку - жесткое требование - никакого STL и внешних зависимостей. Такой пул реквест не примут просто из за наличия STL. Если и решать проблему, то самописной реализацией uninitialized_copy
Я не знаю почему, но хуан очень не любит STL, Boost и шаблоны вложенностью больше чем один уровень. Если приглядется, можно увидеть, что шаблонов в движке мало и они самые поверхностные, покрывающие простейшие контейнеры с упорядоченной памятью, все остальное крутится во круг обьекта Variant
Я не знаю почему, но хуан очень не любит STL, Boost и шаблоны вложенностью больше чем один уровень.
По-моему, нетрудно понять, почему. Особенно касательно шаблонов.
А можете раскрыть почему?
Потому что мне трудно понять, зачем писать на Си-с-классами, вместо использования современного языка и богатых библиотек
Потому что это игровой движок, у которого требования к производительности и памяти отличаются от бизнес-приложений. Большинство игровых движков STL не используют, или имеют собственную реализацию (от EA даже выложена в open source).
Ну предположим, что стандартная STL не очень удобна для игростроя, но шаблоны-то за что? Та же EASTL шаблоны, разумеется, вовсю использует и нахваливает: "you need to understand that templates, when used properly, are powerful vehicles for the ease of creation of optimized C++ code", впрочем, это и без этой их цитаты очевидно любому, кто не застрял в 98 году.
Помню, лет 20 назад использование многоуровневых шаблонов могло серьезно замедлить компиляцию. Было даже, когда компилятор на подобном проекте выдал ошибку в духе "не смогла".
Но сейчас-то, правда, какие проблемы с шаблонами?
Если зайти в исходный код Godot, то в папке modules, core и scene, ты почти с ходу сможешь читать чужой код без документации.
Если зайти в исходный код O3DE, то по одним шаблонам в глубину ты будешь скакать страниц на десять в глубину, что бы понять, что делает та или иная строчка.
Ну и движок рантаймовый.
Т.е. вся игровая логика базируется на примитивных типах (int, float, bool), двух коллекциях и все остальное, производное от них (Vector, String, ...) и все это на рантаймовых рельсах. А скриптовый язык GDScript только внешне похож на питон, но по поведению ближе к плюсам.
Так что да, шаблоны не нужны, только необходимый минимум.
Имел удовольствие дописывать два проприетарных игровых движка - везде STL
Есть какая-то стигма у людей, застрявших в 98 году, что STL это зло и медленно, но практикой ещё никто не смог подтвердить
Понятно, что в узких местах, когда нужен специализированный контейнер/алгоритм, то можно взять boost/abseil/написать своё, но таких мест единицы
я вас обманул =)
На самом деле я знаю почему, но я не согласен с сообществом godot по поводу STL.
А теперь по порядку.
Отладочные символы. Основная претензия сообщества Godot - STL их раздувает сильно. Что бы вы понимали, даже игровой редактор движка весит меньше ста мегабайт.
По поводу шаблонов. Их используют, но ограниченно, просто что бы код был читабельным. Основная претензия, что бы код не был похож на шаблонную вермишель как у буста или другого игрового движка О3DE.
Движком использует под капотом шаблоны, но по минимуму. Там пишут код такой, что бы он был максимально понятным, простым и человеко-читабельным. Т.е. например шаблонный контейнер - да, хэшмап - да, вариант - да.
Шаблон ради шаблона - нет. Глубокие шаблоны, в шаблонах, с авто на шаблонах - нет.
К сожалению, там со времен Godot 2 тянутся макросы, который я бы как раз таки, заменил бы на constexpr шаблоны.
Отладочные символы. Основная претензия сообщества Godot - STL их раздувает сильно. Что бы вы понимали, даже игровой редактор движка весит меньше ста мегабайт.
Отладочные символы в release сборку разве подшиваются? Или они всегда собирают исключительно debug? Возможно, я не понимаю, о чем речь. Я сам против раздувания объема программ, и не могу понять, когда простая на вид программа весит гигабайт (особенно в смартфоне), но сотня мегабайт, кмк - сегодня уже не катастрофа.
Шаблон ради шаблона - нет
Что значит "шаблон ради шаблона", можете пояснить?
Если шаблоны позволяют один и тот же код не размножать на все возможные типы данных, почему бы их не использовать?
Насчёт требования по отсутствию STL не знал, спасибо. Однако у них она все же используется, если сделать поиск в коде по std:: можно найти кое-что. По поводу же данного исправления, опять таки это лишь вариант исправления в общем случае. Кажется, они уже исправляли похожую проблему. По поиску можно найти, например, такой вариант.
ERR_FAIL_COND_MSG((int64_t) p_width * (int64_t) p_height > (int64_t) MAX_PIXELS, "Too many pixels for image, maximum is " + itos(MAX_PIXELS));
А под Armv7 или сборка с флагом scons bits=32 как прикажете?
Все макросы ERR_COND и прочее - это по сути заглушки для рантайма, в режиме редактора и отладки. На релизе, эти макросы превращаются в тыкву (комментарий)
Можно воспользоваться std::ptrdiff_t (или аналогом, если не хочется использовать стандартную библиотеку) вместо int64_t. Подобрать полностью подходящий вариант исправления могут только сами разработчики, так как они знают все тонкости проекта. Я лишь предложил варианты исправления в общем случае, а дальше нужно смотреть, что подойдет лучше.
Я, кстати, создал issue у них на github, и они отписали уже по всем фрагментам.
Не планируете делать PVS анализатор для проектов на gdscript ? )
На текущий момент таких планов нет, но никто не знает, как может сложиться судьба дальше. Например, у нас недавно был внутренний хакатон, и на нем мы писали прототип анализатора для языка Lua. Кстати, скоро опубликуем про это статью :)
А вот и обещанная статья.
Как найти работу для фиксиков: анализируем Godot Engine