История изменений

Могу из давно забытого студенческого: есть матрица исходных значений, нужно по ней пробежаться и пересчитать значения по каким-то формулам с задействованием соседних элементов. Т.е. для элемента [i, j] могут использоваться, например, [i-1, j], [i, j-1], [i, j+1], [i+1, j]. В зависимости от значений i и j у вас может не быть строк (i-1) или (i+1) или столбцов (j-1) или (j+1).

Ну, то есть, погоди. Для вот этой вот срани C++ вообще не нужен, это легко делается на каком-нибудь eDSL, который компилится напрямую в Си или даже в асм. Но даже в C++, такое проверить статически не то чтобы сложно. И такой код составляет даже не 2%, а 0.02% кода в системе. Соответственно, всё остальное можно без проблем завернуть в безопасное надмножество C++ без UB и с проверкой границ, и никто даже не заметит.

Хуже того, это в лёгкую делается на пердоне с numpy.

Но вот как события будут развиваться: народ быстро обнаружит, что operator[] дает оверхэд, а какой-нибудь новый unsafe_at – нет. И начнет фигачить повсюду unsafe_at вместо operator[].

Выходит, твой аргумент тут в том, что средний программист на C++ – тупой мудак и будет делать убогий говнокод, не потрудившись даже потрогать профайлер и посмотреть, действительно ли у него тормозит там где он думает (почти всегда тормозит где-то в другом месте). В принципе, так и есть, но забавно что пишешь об этом ты.

Могу из давно забытого студенческого: есть матрица исходных значений, нужно по ней пробежаться и пересчитать значения по каким-то формулам с задействованием соседних элементов. Т.е. для элемента [i, j] могут использоваться, например, [i-1, j], [i, j-1], [i, j+1], [i+1, j]. В зависимости от значений i и j у вас может не быть строк (i-1) или (i+1) или столбцов (j-1) или (j+1).

Ну, то есть, погоди. Для вот этой вот срани C++ вообще не нужен, это легко делается на каком-нибудь eDSL, который компилится напрямую в Си или даже в асм. Но даже в C++, такое проверить статически не то чтобы сложно. И такой код составляет даже не 2%, а 0.02% кода в системе. Соответственно, всё остальное можно без проблем завернуть в безопасное надмножество C++ без UB и с проверкой границ, и никто даже не заметит.

Но вот как события будут развиваться: народ быстро обнаружит, что operator[] дает оверхэд, а какой-нибудь новый unsafe_at – нет. И начнет фигачить повсюду unsafe_at вместо operator[].

Выходит, твой аргумент тут в том, что средний программист на C++ – тупой мудак и будет делать убогий говнокод, не потрудившись даже потрогать профайлер и посмотреть, действительно ли у него тормозит там где он думает (почти всегда тормозит где-то в другом месте). В принципе, так и есть, но забавно что пишешь об этом ты.