А если захотим написать свой 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 был, и остается с нами надолго. А такой класс решений, на мой взгляд, должен зарубаться еще на уровне идеи. Тем не менее это попало в стандарт.
Решают ли модули проблему инклюдов - не уверен. Опять же, не знаком с темой глубоко на уровне использования, лишь абстрактно. Однако, на мой взгляд, внутри одной библиотеки, коим разработчиком можешь являться, проблема остается все той же
ага, согласен. Но в играх за такой точностью уже никто не следит, и обычно эта проблема решается тем, что тела не абсолютно упруги и часть энергии всегда поглощается при столкновении, в итоге энергия системы точно не растет
нее ) солвер сначала применяет обычные импульсы, чтобы тела разлетались. Если применять только их, то тела будут проникать друг в друга. Поэтому он добавляет еще и "псевдоимпульсы", направленные на то чтобы тела мгновенно "растолкнуть" друг из друга. Эти псевдоимпульсы направлены число на то чтобы тела не проникали друг в друга
Пример с прыгающим мячом - это старый подход, в котором вместо "псевдоимпульсов" применяются настоящие. Которые не только выталкивают, но и задают некоторую скорость. Из-за чего энергия растет
Псевдоимпульсы же не влияют на скорость, но влияют на псевдоскорость. Обычная скорость сохраняется от кадра к кадру, псевдоскосрость же обнуляется на следующем кадре
Это прям отдельная и большая тема ) Газы/жидкости моделируют 2мя способами, насколько я знаю:
частицами. Много-много частиц взаимодействуют друг с другом. Самый распространенный подход в играх
разбиение пространства на кластеры и расчет поведения газа/жидкости в каждой ячейке
В minecraft/teardown я думаю все гораздо проще, там просто у вокселей (кубиков или что там) есть статус горит/не горит, и он распространяется на соседей с некоторым таймером
нет. Мне кажется было бы неплохо чтобы были оба варианта - внешняя и внутренняя функции. Для своей реализации контейнера легко добавить внутреннюю функцию, использующую внешнюю:
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, но самую крутая физика в играх как правило с кастомными физ движками..
ага, согласен. Но в играх за такой точностью уже никто не следит, и обычно эта проблема решается тем, что тела не абсолютно упруги и часть энергии всегда поглощается при столкновении, в итоге энергия системы точно не растет
ээм.. оригинала нет. Физика твердого/мягкого тела - это общие понятия в игровой физике, вероятно к остальному миру физики это не особо применимо :)
я б поиграл!
У меня телеге есть небольшой пост про физику самолета. Но там все сильно упрощено
нее ) солвер сначала применяет обычные импульсы, чтобы тела разлетались. Если применять только их, то тела будут проникать друг в друга. Поэтому он добавляет еще и "псевдоимпульсы", направленные на то чтобы тела мгновенно "растолкнуть" друг из друга. Эти псевдоимпульсы направлены число на то чтобы тела не проникали друг в друга
Пример с прыгающим мячом - это старый подход, в котором вместо "псевдоимпульсов" применяются настоящие. Которые не только выталкивают, но и задают некоторую скорость. Из-за чего энергия растет
Псевдоимпульсы же не влияют на скорость, но влияют на псевдоскорость. Обычная скорость сохраняется от кадра к кадру, псевдоскосрость же обнуляется на следующем кадре
Нет ничего после выкладки не правил. Для пуль используется трассировка, либо continous collision detection. Он есть в статье вкратце
мой любимый видос про физические глитчи - skate 3 )
Это прям отдельная и большая тема ) Газы/жидкости моделируют 2мя способами, насколько я знаю:
частицами. Много-много частиц взаимодействуют друг с другом. Самый распространенный подход в играх
разбиение пространства на кластеры и расчет поведения газа/жидкости в каждой ячейке
В minecraft/teardown я думаю все гораздо проще, там просто у вокселей (кубиков или что там) есть статус горит/не горит, и он распространяется на соседей с некоторым таймером