Мне кажется, кое-кто не учитывает такой фактор, как время разработки. Да, можно писать офигенно быстрые штуки на Си, велосипедить списки, сортировки и прочее. Но нафига? Писать, сравнивать производительность, искать ошибки. Придётся расстаться либо с надёжностью, либо со временем, которое уйдёт на тестирование.
Из
википедии: "Учёный
Йон Бентли утверждает, что 90 % студентов, разрабатывая двоичный поиск, забывают учесть какое-либо из этих требований. И даже в код, написанный самим Йоном и ходивший из книги в книгу, вкралась ошибка: код не стоек к переполнениям"
Обычное сложение векторов a = b + c превращается в
vec3_t a,b,c; Vector3_Set( &b, 1, 2, 3 ); Vector3_Set( &c, 3, 4, 5 ); Vector3_Add( &c, &b, &c );
Но после того как написал физику для игры( а там сплошные вектора кругом ), стало привычно. Кстати напоминает математику из D3DX.
|
Опять же, когда есть готовый алгоритм, подобный код писать можно.
Но если алгоритм разрабатывать "на ходу", пробовать менять различные его части, сравнивать точность вычислений и прочее, то код вида a = b+c намного проще для изменений и поиска ошибок.
Кстати, одна ошибка уже есть: в твоём примере c = b+c.
Кроме того, не раскрыта тема высокоуровневых оптимизаций. В С++ или java я могу в несколько строчек заменить, например, реализацию списка с ArrayList на LinkedList и этим повлиять на производительность.
Значительная часть потерь скорости зависит не от константы времени выполнения, а от ассимптотики - судя по моему опыту, возможность легко и быстро писать/изменять код даёт намного больший бонус, чем мелкие локальные оптимизации.
Кроме того, всякие локальные оптимизации есть смысл использовать только в "бутылочном горлышке", в остальных случаях можно забить и не тратить своё время.