Итераторы

[Old]

Когда-то аккуратно/грамотно было так

Это и сейчас грамотней и эффективней.

И это действительно работало быстрее, пусть и немного. Но время это давным-давно миновало, поэтому ссылаться на мифическую скорость итератора неуместно

Это и сейчас работает быстрее. Никуда эти времена не миновали и не минуют никогда. Не будет никогда процессоров, выполняющих некоторые команды за 0 тактов. Больше команда, больше тактов. И не важно, что это всего несколько тактов на итерацию.

[Igors]

А то тут на нужен random-access к коллекции, а итераторы здесь как козе баян.

Ага, оказывается не всегда итераторы - обязательно лучшее решение.

Давайте мы не будем хранить индексы.

А что, адреса? Это имеет далеко идущие последствия - они должны быть неперемещаемы, для таких элементов как QPont3D размер данных возрастает вдвое. Ну хорошо, используйте др контейнер на Ваш вкус - может там покажете силу итераторов.

примерный набросок - http://liveworkspace.org/code/cIG2U

Ну что сказать - очень современный код, я так не напишу (хотя читал о всех средствах что Вы используете). Однако функционал безобразен

- copy/paste кода печати удручает, это ф-ция
- был треугольник напр (0, 10, 11).  Если точка 1 (напр) удалена, то треугольник должен стать  (0, 9, 10)
- erase (в цикле) и find дорогие операции. Тормоза будут уже на 10K данных (1k) удаляемых - а ведь это детский объем. А там ведь легко получается пресловутое O(n)

Однако при всем этом alex312 - единственный кто подтвердил свой подход кодом. Поэтому прошу считать мои замечания конструктивной критикой.

[Old]

Ага, оказывается не всегда итераторы - обязательно лучшее решение.

Ах эти крайности, крайности, крайности....
Конечно не всегда, в программирование не бывает обязательно лучших решений.

Вы не читаете мои посты? В одном из них я написал в каких случаях итераторы эффективней.

[Igors]

Не будет никогда процессоров, выполняющих некоторые команды за 0 тактов. Больше команда, больше тактов. И не важно, что это всего несколько тактов на итерацию.

Если мы так умело считаем такты, то объясните почему совершенно провальная по скорости реализация не вызвала у Вас никакой реакции? Ведь можно сделать на порядок быстрее - и код не длиннее.

Мне кажется потому что голова занята не задачей и не поиском лучшего решения, а отеми цацками-пецками (типа std::array <int, 3>). И чем более утонченные средства применяются - тем хуже результат 

[Old]

Если мы так умело считаем такты, то объясните почему совершенно провальная по скорости реализация не вызвала у Вас никакой реакции? Ведь можно сделать на порядок быстрее - и код не длиннее.

А какая у меня должна быть реакция? Человек захотел сделать реализацию с итераторами, мне нужно было его поругать?

Мне кажется потому что голова занята не задачей и не поиском лучшего решения, а отеми цацками-пецками (типа std::array <int, 3>).

А я никакие задачи не решаю и никаких решений не ищу.

И чем более утонченные средства применяются - тем хуже результат

Мне очень жаль, что у вас так происходит. Но, с другой стороны, никто и не заставляет ими пользоваться.

[Igors]

А я никакие задачи не решаю и никаких решений не ищу.

Так приходит старость..

[RedDog]

В нижеприведенном коде, итераторы быстрее в 2 раза (в релизе)

Код

C++ (Qt)
void Widget::on_test2_clicked()
{
    std::vector<int> tmp;
    int i = 0;
    tmp.resize(1000000);
 
    std::vector<int>::iterator it = tmp.begin();
    QTime timer;
    timer.start();
    for (int m = 0; m < 10000; ++m)
    {
        for(; it != tmp.end(); ++it)
        {
            (*it) = i + 1;
            ++i;
        }
        it = tmp.begin();
        for(; it != tmp.end(); ++it)
        {
            i = (*it);
        }
    }
    ui->label_2->setText(QString::number(timer.elapsed()));
 
 
}
 
void Widget::on_pushButton_clicked()
{
    std::vector<int> tmp;
    int j = 0;
    tmp.resize(1000000);
    QTime timer;
    timer.start();
    for (int m = 0; m < 10000; ++m)
    {
        size_t i = 0;
        for (; i < 1000000; ++i)
        {
            tmp[i] = j + 1;
            ++j;
        }
        i = 0;
        for (; i < 1000000; ++i)
        {
            j = tmp[i];
        }
    }
    ui->label->setText(QString::number(timer.elapsed()));
}
 

Что интересно, в дебаге все наоборот.

[Old]

Так приходит старость..

Да.
Сейчас вообще занялся идиотизмом, снова пишу код для Commodore 64 (процессор 6502). Ассемблер only, считаю такты, генерирую pre-calc таблицы, оптимизирую память...
В общем, занимаюсь детством и мне совсем не интересно участвовать в столь грандиозной теме, как: "Языку C++ скоро 30 лет, а мы только сейчас  добрались до главы при итераторы".

[xokc]

В нижеприведенном коде, итераторы быстрее в 2 раза (в релизе)

Неитераторный код-то неадекватен. Тут нужно было int tmp[1000000] вместо std::vector<int> tmp использовать. И боюсь, что в этом случае результаты в релизе бы совпали с точностью до погрешности измерений.
А вообще, опять же в таких примитивных случаях многое зависит от оптимизаторских способностей компилятора, а вовсе не от использования итераторов.

[Old]

Тут нужно было int tmp[1000000] вместо std::vector<int> tmp использовать.

Почему?

[RedDog]

Неитераторный код-то неадекватен. Тут нужно было int tmp[1000000] вместо std::vector<int> tmp использовать. И боюсь, что в этом случае результаты в релизе бы совпали с точностью до погрешности измерений.

Исходя из первого поста - необходимо обходить контейнер либо итератором либо через индекс.

А вообще, опять же в таких примитивных случаях многое зависит от оптимизаторских способностей компилятора, а вовсе не от использования итераторов.

Ну разница в 2+ раза думаю включает в себя не только оптимизацию компилятора, но и оптимизацию алгоритма.

[xokc]

Тут нужно было int tmp[1000000] вместо std::vector<int> tmp использовать.

Почему?

Потому, что иначе сравнивается не производительность итераторного/неитераторного подхода, а производительность vector::operator[] и инкрементирования указателя через operator++. Результат очевиден ведь - о чём тут вообще рассуждать?

Исходя из первого поста - необходимо обходить контейнер либо итератором либо через индекс.

Тогда уж обходите контейнер через int *tmpPtr = tmp.data() и дальше используйте tmpPtr.

Ну разница в 2+ раза думаю включает в себя не только оптимизацию компилятора, но и оптимизацию алгоритма.

Оптимизация компилятором и состоит именно в том, чтобы свести эти алгоритмы к одному и тому же.

А вообще про производительность примитивных итераторов много сказано тут
http://www.viva64.com/ru/b/0093/
Автор там приходит ко вполне очевидному выводу - в релизе нет никакой разницы между такими примитивными проверками. Любой разумный комплилятор сведет ваш код к одному и тому же.
Там же еще одна интересная мысль "не пришло ли то самое страшное время, когда в программе появляются свои собственные специализированные классы строк, массивов и так далее..."
Но это - тема для совсем другой дискуссии.

[Old]

о чём тут вообще рассуждать?

Здесь я с вами полностью согласен.

[RedDog]

xokc зачем ставить все с ног на голову? В первом посте сказано: либо итераторы, либо через []. В рамках этого я и привел пример. Если по твоему рассуждать, то можно вообще все на указателях замутить, тогда разницы не будет нигде.
А инкримент итератора и указателя для данного примера(имхо), по скорости равнозначен.

[xokc]

xokc зачем ставить все с ног на голову? В первом посте сказано: либо итераторы, либо через []. В рамках этого я и привел пример.

Если смотреть на первый пост, то речь там вообще шла не о переборе значений, а о "демонстрации мощи итераторов" при удалении элемента. Так что от темы мы тут все уже далеко уклонились

Если по твоему рассуждать, то можно вообще все на указателях замутить.

Я именно так всегда и стараюсь делать, а не применять итераторы всюду, лишь бы это было модно. Да и вектора стараюсь применять только там, где мне это удобнее чем просто массив на стеке.

А инкримент итератора и указателя для данного примера(имхо), по скорости равнозначен.

Где я утверждал обратное?

А вообще от этой темы я уже устал. По моему тут уже давно всем всё ясно и дискуссия идёт просто ради дискуссии.