Комментарии 4
А если писать код на голых
mallocиfree, вылавливать утечки будет еще одним повседенным занятием. А вот найти, какой именно из пятисот вызовов выделения памяти не получил свойfreeэто задача со звездочкой. Если думаете, что умный GC или умные указатели решают эту проблему, то нет... не решают. Они просто меняют природу утечек и вместо утечки памяти получаем утечку ссылок и какой‑нибудь забытый менеджер сцены продолжает держать ссылку на невидимый объект, а тот по цепочке держит текстуры и звуки.
как мне кажется на С++ зависит от архитектуры... (+ если модули, если удобно настроено иде отловить можно я всё еще думаю), просто, чтобы легаси 10к-100к loc покидать по модулям и сохранить архитектуру времени уйдёт конечно, это понятно конечно....
В идеальном мире правильного и красивого кода - разработка этого самого кода стоила ровно ноль центов за тыщу лет работы, а дедлайн был через сто тыщ (световых) лет... соответственно, было комфортно работать со скоростью "одна отлаженная строка в час". И в те стародавние времена, когда этот мир, по некоторым слухам, существовал, бывали в самом деле программы без единого бага. Слухи упорно сватают на эту роль LaTeX, например. Так это или нет - не знаю.
В мире реальном и современном, увы, писать приходится чуток побыстрее. А скоропись, точнопись и красивопись почему-то не очень хорошо уживаются вместе. Не только в программировании. В обычном рисовании тоже. Даже когда рисует или пишет какой-нибудь дядюшка Клод.
Проблема сия едва ли устранима. Но - это "фичебаг", который, собственно, и дает рабочие места тем, кто занимается переработкой хитина...
Плата за производительность - вещь универсальная, у нее есть лишь два измерения: цена и качество. Если при этом цена фиксирована, то что страдает - увы, вопрос риторический. С тем и живём
Многопоточные гонки, кстати, отчасти диагностируются thread sanitizer'ом.
Иногда тсан даёт ложноположительные срабатывания, но каждое из них нужно убедительно доказывать, что оно именно ложно положительное.
Чем дальше от начала координат, тем... дело даже не в ошибках конечной разрядности плавающей арифметики, а в ошибках вообще.
Преобразования систем координат делаются на матрицах, в одну сторону - на прямых, в обратную - на обратных. Если матрица плохо обусловлена, оператор преобразования становится люто чувствителен к малым изменениям (в том числе, к погрешностям любой природы - хоть из младших разрядов, хоть из физики).
И хотя с позиций чистой математики любое аффинное преобразование можно представить как матричное умножение в N+1-мерном пространстве (вектор-точка аугментирован единичкой, вектор-длина - ноликом), или же, что то же самое, как последовательность из вращения-масштабирования - матричного умножения в N-мерном пространстве - и затем параллельного переноса,
вот специально для таких ситуаций лучше не умничать, а разложить преобразование как последовательность произвольных вращений и переносов, - а обратное преобразование сыграть ровно в обратном порядке: отрицательный перенос, обратное вращение, отрицательный перенос, обратное вращение...
Отдельный ад возникает при интер- и экстраполяции движения. Там получается набор интерполированных преобразований, которые надо применять к исходной точке. А интерполяция - это всегда те самые малые изменения. Которые с плохо обусловленными матрицами делают очень больно!
Поэтому интерполировать нужно в какой-то локальной системе координат.
Интерполяция, опять же, бывает разная. Самые очевидные схемы - это линейная (слерп кватернионов и лерп положения) или матричная экспонента (движение по дуге).
Но вот беда, матричная экспонента вычисляется через матричный ряд Тейлора. С ограниченной точностью. То есть, с заданной погрешностью. Поэтому те самые малые изменения у нас зашумлены по определению!
И это не только геймдева касается, но и моделирования движения в реальном географическом пространстве.
Хорошо промышленному роботу: прикручен к станине или, максимум, катается по цеху. А вот беспилотный автомобиль или летательный аппарат отхватывает все эти нюансы вычислительной математики полной ложкой!

Анатомия граблей