для мобильных игр - это весьма прилично. Если поддерживать слабые девайсы с 1ГБ ОЗУ, то приложению по факту доступно всего около 600мб. В таком случае 35мб может оказаться критично
Это и правда классный подход, но имхо не для всего подходит. Все таки игра не это не только (и далеко не всегда) туча бегающих юнитов, куча рассчетов и т.п. Есть куча UI, особенно в мобайле, где все это просто вредит, т.к. код становится сильно сложнее.
Для такой не требовательной к производительности логике нужно максимальное удобство, и в С++ это дают умные указатели и более простая схема работы
кхм.. мной, с учетом платформ. Ничего специфичного пока в моих планах нет, скорее всего размера 4 + 4 будет достаточно для всех платформ - ios/andoird/mac/win/linux/web. Ну а если понадобится, конечно, добавлю выравнивание здесь
Да, если без фанатизма, то все впорядке. На крайний случай в какие-то тяжелые алгоритмы можно и сырой указатель передать. Умные указатели решают проблему утечек и менеджмента памяти, что в играх весьма актуально
Это работает чисто из-за оптимизации компилятора. Факт остается фактом - это два поинтера. Сравнивать два поинтера, надеясь что там одинаковые данные - не очень хорошо
Сложения строк у вас нет, поставьте между ними плюс. Компилятор считает это одной строкой
И обратите внимание, как пришлось протаскивать конструкторы через два шаблонных класса, чтобы my_vector можно было проинициализировать так же легко, как и std::vector.
my_vector здесь чисто ради примера, потому что std::vector модифицировать я не могу.
Раскомментируйте последнюю строку в функции abcx() и заставьте работать ваш вариант так же, как работает вариант с функцией abcy().
я согласен, чуток универсальности теряется. Но это довольно синтетический кейс, по крайней мере для меня. Мне гораздо чаще нужна работа с конкретной коллекцией. А таких шаблонных функций с алгоритмами внутри мало, над ними можно попариться
весь этот бойлерплейт будет написан в стандартной либе. Можно все завернуть в mixin, тогда вся эта портянка будет описана один раз. В своих коллекциях можно будет так же юзать стандартный mixin
Зачем вы упираетесь в ограничение что либо так, либо сяк? Я про удобство кодирования, от лишней функции внутри контейнера ничего страшного не случится. А все внешние функции пусть остаются внешними и гибкими. Речь же про 99% случаев когда тебе нужно передавать begin()/end() - а это тупая работа
Ну почему же, пробовал. Вот как используется. Пока что это лучшая реализация, которую я получил. Но она всратая - хреновый синтаксис в виде макроса, поле проперти хранит минимум один указатель внутри, генерится туева хуча микро-классов, и я надеюсь что их оптимизирует компилятор. Но нужный функционал дает
Другие реализации либо хуже по памяти, либо по производительности.
Но если бы это работало на уровне языка, никаких этих минусов не было бы. Конструкция object.position = object.position + other.position; заменялась бы просто на пачку сеттеров и геттеров
Да ну нет, я примерно понимаю почему пришли к таким решениям. Но это не значит что они хорошие. Меня не устраивают текущие решения, я постарался описать свои идеи как это могло быть. Критика - тоже важная часть нахождения консенсуса
Очень даже тянут )
интересно, спасибо ) но мне как раз хоть какой-то размер нужен, т.к. в через рефлексию могу ссылаться на property по указателю
Так вот в начае же как раз, чтобы иметь нормальный синтаксис математических операций
actor.transform = left.transformrigh.transformup.transform;для мобильных игр - это весьма прилично. Если поддерживать слабые девайсы с 1ГБ ОЗУ, то приложению по факту доступно всего около 600мб. В таком случае 35мб может оказаться критично
По сути этот вариант эквивалентен
SCOPE_EXIT.Автор пишет что такой вариант помог, но еще оставались некомпилируемые тестыСогласен, немного дополнил это место. Спасибо!
Это и правда классный подход, но имхо не для всего подходит. Все таки игра не это не только (и далеко не всегда) туча бегающих юнитов, куча рассчетов и т.п. Есть куча UI, особенно в мобайле, где все это просто вредит, т.к. код становится сильно сложнее.
Для такой не требовательной к производительности логике нужно максимальное удобство, и в С++ это дают умные указатели и более простая схема работы
Плюсую. Как бы аккуратно не был сделан менеджмент памяти в движке, в игровом коде будет ад и содомия
кхм.. мной, с учетом платформ. Ничего специфичного пока в моих планах нет, скорее всего размера 4 + 4 будет достаточно для всех платформ - ios/andoird/mac/win/linux/web. Ну а если понадобится, конечно, добавлю выравнивание здесь
Хм, и я так считал. Но у меня буквально был опыт сравнения двух подходов - сырыу указатели в домашнем проекте и умные на работе.
Тем более что движко позволяет писать игровую логику на С++, и там вероятность ошибки слишком велика. Поэтому умные указатели здесь решают
В целом да, здесь явно не учтено выравнивание, но блок счетчика подбирается как раз под размер выравнивания, поэтому проблемы нет
На самом деле с умными указателями не так все плохо. В целом накладные ресурсы довольно маленькие, а со счетчиком перед объектом и вовсе мизерные
Да, если без фанатизма, то все впорядке. На крайний случай в какие-то тяжелые алгоритмы можно и сырой указатель передать. Умные указатели решают проблему утечек и менеджмента памяти, что в играх весьма актуально
В россии очень любят две вещи: хаять что ничего своего не делают и хаять когда делают свое
Это работает чисто из-за оптимизации компилятора. Факт остается фактом - это два поинтера. Сравнивать два поинтера, надеясь что там одинаковые данные - не очень хорошо
Сложения строк у вас нет, поставьте между ними плюс. Компилятор считает это одной строкой
На лицо skill issues )))
my_vectorздесь чисто ради примера, потому что std::vector модифицировать я не могу.я согласен, чуток универсальности теряется. Но это довольно синтетический кейс, по крайней мере для меня. Мне гораздо чаще нужна работа с конкретной коллекцией. А таких шаблонных функций с алгоритмами внутри мало, над ними можно попариться
весь этот бойлерплейт будет написан в стандартной либе. Можно все завернуть в mixin, тогда вся эта портянка будет описана один раз. В своих коллекциях можно будет так же юзать стандартный mixin
https://gcc.godbolt.org/z/zbT5d7Mx5
Зачем вы упираетесь в ограничение что либо так, либо сяк? Я про удобство кодирования, от лишней функции внутри контейнера ничего страшного не случится. А все внешние функции пусть остаются внешними и гибкими. Речь же про 99% случаев когда тебе нужно передавать begin()/end() - а это тупая работа
Ну почему же, пробовал. Вот как используется. Пока что это лучшая реализация, которую я получил. Но она всратая - хреновый синтаксис в виде макроса, поле проперти хранит минимум один указатель внутри, генерится туева хуча микро-классов, и я надеюсь что их оптимизирует компилятор. Но нужный функционал дает
Другие реализации либо хуже по памяти, либо по производительности.
Но если бы это работало на уровне языка, никаких этих минусов не было бы. Конструкция
object.position = object.position + other.position; заменялась бы просто на пачку сеттеров и геттеровДа ну нет, я примерно понимаю почему пришли к таким решениям. Но это не значит что они хорошие. Меня не устраивают текущие решения, я постарался описать свои идеи как это могло быть. Критика - тоже важная часть нахождения консенсуса