Это и правда классный подход, но имхо не для всего подходит. Все таки игра не это не только (и далеко не всегда) туча бегающих юнитов, куча рассчетов и т.п. Есть куча 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; заменялась бы просто на пачку сеттеров и геттеров
Да ну нет, я примерно понимаю почему пришли к таким решениям. Но это не значит что они хорошие. Меня не устраивают текущие решения, я постарался описать свои идеи как это могло быть. Критика - тоже важная часть нахождения консенсуса
А если захотим написать свой stl-compliant контейнер и реализовать для него find_if? Писать с нуля?
нет. Мне кажется было бы неплохо чтобы были оба варианта - внешняя и внутренняя функции. Для своей реализации контейнера легко добавить внутреннюю функцию, использующую внешнюю: auto find_if(xxx) { return std::find_if(begin(), end(), xxx); }
Но сколько раз за все время вы писали свой контейнер? А сколько раз вы набрали begin(), end() ? Вот буквально предлагаю провести эксперимент и найти все вхождения этой подстроки в вашем текущем рабочем проекте
есть пример в статье - это изменение позиции гейм-обжекта. После ее изменения нужно пересчитать матрицу трансформации. То есть для установки позиции должна быть вызвана функция
По сути этот вариант эквивалентен
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; заменялась бы просто на пачку сеттеров и геттеровДа ну нет, я примерно понимаю почему пришли к таким решениям. Но это не значит что они хорошие. Меня не устраивают текущие решения, я постарался описать свои идеи как это могло быть. Критика - тоже важная часть нахождения консенсуса
нет. Мне кажется было бы неплохо чтобы были оба варианта - внешняя и внутренняя функции. Для своей реализации контейнера легко добавить внутреннюю функцию, использующую внешнюю:
auto find_if(xxx) { return std::find_if(begin(), end(), xxx); }Но сколько раз за все время вы писали свой контейнер? А сколько раз вы набрали
begin(), end()? Вот буквально предлагаю провести эксперимент и найти все вхождения этой подстроки в вашем текущем рабочем проектебунд!11
тем что нужно использовать литерал. А к литералу еще и using
есть пример в статье - это изменение позиции гейм-обжекта. После ее изменения нужно пересчитать матрицу трансформации. То есть для установки позиции должна быть вызвана функция