Здравствуйте, netch80, Вы писали:

L>>Во-первых, don't write shit code. Моей фантазии не хватает на то, чтобы представить, как можно в коде транспонирования матрицы случайно такой косяк допустить.
N>Для 17 — да, для 16 — уже запросто — при попытке ускорения через SSE/AVX/etc.

О, хороший пример, как раз показывающий полезность юнит-тестирования.
Подобные подкапотные оптимизации не изменяют наблюдаемого поведения. Но это не случайное изменение, и разработчк, реализующий подобную оптипизацию, понимает, что он вносит еще один граничный случай в код (если он не понимает, то это уже нужно обсужать в форуме "о работе"). И знает, что ему нужно написать тест, который протестирует работу юнита именно в этих условиях. И он этот тест пишет, и не ждет, когда придет баг репорт из продакшена.

L>>Во-вторых, проверка стрельбы по памяти не входит в ответственность юнит-тестов. Я в принципе не уверен, что ее можно в общем случае обнаружить в момент собственно выстрела.
N>В общем случае — нет. В достаточно простых — например, порча соседних участков из-за вылезания за границы на плюс-минус константу — есть хорошо проработанные методы с guard zone.

Вот и я про то. Кроме того, налицо двойные стандарты — методом ручного лома код на отсутствие привычки стрелять по памяти не проверить от слова никак. А вот от юнит-тестов начинают внезапно требовать еще и это, и многое другое.