весь этот бойлерплейт будет написан в стандартной либе. Можно все завернуть в 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() ? Вот буквально предлагаю провести эксперимент и найти все вхождения этой подстроки в вашем текущем рабочем проекте
есть пример в статье - это изменение позиции гейм-обжекта. После ее изменения нужно пересчитать матрицу трансформации. То есть для установки позиции должна быть вызвана функция
Это избавляет от необходимости писать весь этот код для самописных контейнеров
кого избавляет, разработчика стандартной либы? Давайте будем честны, мы чаще используем контейнеры, чем пишем свои. Я не против внешних универсальных функций, но почему бы их не продублировать в стандартных контейнерах?
Just use c++20 and requires
согласен, выше по коментам уже указали на этот косяк статьи. Однако все равно SFINAE с нами, и я считаю это одним из самых плохих архитектурных решений что я видел
Нельзя.
можно. Например, передав заранее счетчик ссылок до работы конструктора
сорри, не понял про setter/getter для вектора... setter/getter у меня упоминается в пропертях, которые удобно их заворачивают, это не только к векторам и контейнерам относится, а ко всему
с инклюдами проблема в том что их все равно надо делать, а для уменьшения инклюдов все равно нужно писать forward declaration'ы. Это все тупая работа по решению зависимостей, которую в других языках перекладывают на кмпилятор
Нет, зачем весь код С++ мира, только локального проекта. Грубо говоря сначала все распарсить, собрать AST. Решить все зависимости. А потом уже генерить код. Можно представить это как некую аналогию precompiled header'а на весь проект и forward declaration всех типов
Согласен, мой косяк в том что я не разобрался в концептах... если это решает проблему SFINAE, то с темой явно стоит ознакомиться не по-диагонали. Все же отмечу что SFINAE был, и остается с нами надолго. А такой класс решений, на мой взгляд, должен зарубаться еще на уровне идеи. Тем не менее это попало в стандарт.
Решают ли модули проблему инклюдов - не уверен. Опять же, не знаком с темой глубоко на уровне использования, лишь абстрактно. Однако, на мой взгляд, внутри одной библиотеки, коим разработчиком можешь являться, проблема остается все той же
ага, согласен. Но в играх за такой точностью уже никто не следит, и обычно эта проблема решается тем, что тела не абсолютно упруги и часть энергии всегда поглощается при столкновении, в итоге энергия системы точно не растет
весь этот бойлерплейт будет написан в стандартной либе. Можно все завернуть в 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
есть пример в статье - это изменение позиции гейм-обжекта. После ее изменения нужно пересчитать матрицу трансформации. То есть для установки позиции должна быть вызвана функция
кого избавляет, разработчика стандартной либы? Давайте будем честны, мы чаще используем контейнеры, чем пишем свои. Я не против внешних универсальных функций, но почему бы их не продублировать в стандартных контейнерах?
согласен, выше по коментам уже указали на этот косяк статьи. Однако все равно SFINAE с нами, и я считаю это одним из самых плохих архитектурных решений что я видел
можно. Например, передав заранее счетчик ссылок до работы конструктора
вот здесь: "Ну да, это приходится писать "
:))))
сорри, не понял про setter/getter для вектора... setter/getter у меня упоминается в пропертях, которые удобно их заворачивают, это не только к векторам и контейнерам относится, а ко всему
с инклюдами проблема в том что их все равно надо делать, а для уменьшения инклюдов все равно нужно писать forward declaration'ы. Это все тупая работа по решению зависимостей, которую в других языках перекладывают на кмпилятор
Нет, зачем весь код С++ мира, только локального проекта. Грубо говоря сначала все распарсить, собрать AST. Решить все зависимости. А потом уже генерить код. Можно представить это как некую аналогию precompiled header'а на весь проект и forward declaration всех типов
Согласен, мой косяк в том что я не разобрался в концептах... если это решает проблему SFINAE, то с темой явно стоит ознакомиться не по-диагонали. Все же отмечу что SFINAE был, и остается с нами надолго. А такой класс решений, на мой взгляд, должен зарубаться еще на уровне идеи. Тем не менее это попало в стандарт.
Решают ли модули проблему инклюдов - не уверен. Опять же, не знаком с темой глубоко на уровне использования, лишь абстрактно. Однако, на мой взгляд, внутри одной библиотеки, коим разработчиком можешь являться, проблема остается все той же
it_union, харе классы набирать, высасывая желчь из популярных тем. Роблокс - отличная платформа для развития и творчества.
Просто не настроена коллизия ткани самой с собой, в итоге она проникает через себя
Честно говоря не знаю. Думаю это все хаками делается
Наверное самый продвинутый - PhysX, но самую крутая физика в играх как правило с кастомными физ движками..
ага, согласен. Но в играх за такой точностью уже никто не следит, и обычно эта проблема решается тем, что тела не абсолютно упруги и часть энергии всегда поглощается при столкновении, в итоге энергия системы точно не растет
ээм.. оригинала нет. Физика твердого/мягкого тела - это общие понятия в игровой физике, вероятно к остальному миру физики это не особо применимо :)
я б поиграл!
У меня телеге есть небольшой пост про физику самолета. Но там все сильно упрощено