История изменений
Исправление eao197, (текущая версия) :
Покажи мне пример серьёзной обработки данных.
Ну блин, мне больше делать нечего, ага. Из проектов для заказчиков таскать куски не могу, а искать чего-то похожего лень.
Могу из давно забытого студенческого: есть матрица исходных значений, нужно по ней пробежаться и пересчитать значения по каким-то формулам с задействованием соседних элементов. Т.е. для элемента [i, j]
могут использоваться, например, [i-1, j]
, [i, j-1]
, [i, j+1]
, [i+1, j]
. В зависимости от значений i и j у вас может не быть строк (i-1) или (i+1) или столбцов (j-1) или (j+1).
Таких штуковин в вычислительных задачах, насколько я помню, вагон и маленькая тележка.
Решаются кем?
Всеми, кто про это знает.
Здесь штука в том, что мы можем сократить количество кода, в котором потенциально может быть ошибка, со 100% до 2%. То есть, в 50 раз. И мы сможем гарантировать, что в 98% кода этой ошибки не будет.
Про гарантии ниже.
Чувак, средняя C++-обезьяна понятия не имеет про разницу между .at() и []. Я не шучу.
Тут вот какое дело. Я не против, чтобы в C++ в стандартных контейнерах добавили проверку в operator[]
. Не знаю, правда, как быть с голыми указателями, работа с которыми все еще широко используется.
Но вот как события будут развиваться: народ быстро обнаружит, что operator[]
дает оверхэд, а какой-нибудь новый unsafe_at
– нет. И начнет фигачить повсюду unsafe_at
вместо operator[]
.
И все гарантии пойдут по известному адресу.
Исходная версия eao197, :
Покажи мне пример серьёзной обработки данных.
Ну блин, мне больше делать нечего, ага. Из проектов для заказчиков таскать куски не могу, а искать чего-то похожего лень.
Могу из давно забытого студенческого: есть матрица исходных значений, нужно по ней пробежаться и пересчитать значения по каким-то формулам с задействованием соседних элементов. Т.е. для элемента [i, j]
могут использоваться, например, [i-1, j]
, [i-1, j]
, [i, j-1]
, [i, j+1]
, [i+1, j]
. В зависимости от значений i и j у вас может не быть строк (i-1) или (i+1) или столбцов (j-1) или (j+1).
Таких штуковин в вычислительных задачах, насколько я помню, вагон и маленькая тележка.
Решаются кем?
Всеми, кто про это знает.
Здесь штука в том, что мы можем сократить количество кода, в котором потенциально может быть ошибка, со 100% до 2%. То есть, в 50 раз. И мы сможем гарантировать, что в 98% кода этой ошибки не будет.
Про гарантии ниже.
Чувак, средняя C++-обезьяна понятия не имеет про разницу между .at() и []. Я не шучу.
Тут вот какое дело. Я не против, чтобы в C++ в стандартных контейнерах добавили проверку в operator[]
. Не знаю, правда, как быть с голыми указателями, работа с которыми все еще широко используется.
Но вот как события будут развиваться: народ быстро обнаружит, что operator[]
дает оверхэд, а какой-нибудь новый unsafe_at
– нет. И начнет фигачить повсюду unsafe_at
вместо operator[]
.
И все гарантии пойдут по известному адресу.