LINUX.ORG.RU

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

Исправление 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[].

И все гарантии пойдут по известному адресу.