В векторе он не быстрее, а может даже наоборот. Обращение по индексу - прямой доступ к данным без прослойки в виде итератора.

djamshud, обращение по индексу - это *(base+index) а обращение через итератор это *iterator.
feel the difference

GoldFinch, 









feel the difference 

djamshud, и что? я не юзаю гцц, я хз что это за время, и плохая оптимизация гцц - проблемы гцц

если ты хотел этим доказать что гцц - плохой компилятор, тебе это удалось, поздравляю

Это сообщение отредактировал(а) GoldFinch - 19.12.2009, 00:34

GoldFinch, а при чем тут оптимизация? Мы же говорим об идее итератор Vs индекс, а не о том, как ее извратит оптимизатор. Именно поэтому оптимизация была совсем выключена.

Про цифры поясню. Процессор работает в двух режимах (реально может в большем количестве) - режиме пользователя (обычный режим, числодробления и пр) и режиме ядра (это системные вызовы, обращение к железу). Программа с итератором выполнялась 4.388 секунды в режиме пользователя и 0.040 - в режиме ядра. Всего она "прожила" 4.514 секунд (процессор был занят не толькой ей, поэтому sys+usr!=real). Программа с индексом работала почти в четыре(!) раза меньше, т.е. быстрее.

djamshud, жги еще

Добавлено через 2 минуты и 48 секунд
хоть и говорили недавно, что без профайлера нельзя ничего сказать о быстродействии кода,
но всетаки программисту надо самому понимать что он делает и во что компилится его код, иначе это будет называться 100%-м быдлокодингом.

>хоть и говорили недавно, что без профайлера нельзя ничего сказать о быстродействии кода,
но всетаки программисту надо самому понимать что он делает и во что компилится его код, иначе это будет называться 100%-м быдлокодингом.

И это говорит человек, уповающий на оптимизацию компилятора? Ууух, жгунишка!

Добавлено через 2 минуты и 9 секунд
>без профайлера нельзя ничего сказать о быстродействии кода

Т.е. на самом деле четырехкратный слив как бэ намекает нам, что программа просто разминается перед тем, как попасть в профайлер? Там то она точно даст жару!

Добавлено через 10 минут и 14 секунд
>если ты хотел этим доказать что гцц - плохой компилятор, тебе это удалось, поздравляю

Посмеялся. Блажен неведающий.

Для Zhekin,
Опред. "итерация"
И я с этим согласен.

По твоим примерам, небольшая, однако итераторы, как мне думается, следует применять в конструкциях вроде стандартных алгоритмов или при необходимости задания некоторого порядка следования элементов при итерации (некий "интеллектуальный" вариант). В остальных случаях дело за автором кода.

ЗЫ
Сильно ИМХО: В остальных случаях предпочитаю классический вид обхода элементов массива. Думается он как-то нагляднее показывает работу кода, чем все эти .begin(), .end(), "..элемент, следующий за последним..." и остальное, т.е., иными словами, как-то проще читать код.

не гони. не раз было доказано, что gcc оптимизирует превосходно, и поставляемая с ним stl лучше микрософтофской.

Добавлено @ 06:16

  

Это сообщение отредактировал(а) andrew_121 - 19.12.2009, 06:16

Я последнее время предпочитаю такой способ 



Удобно.

Добавлено через 6 минут и 28 секунд

Вероятнее всего, после оптимизации, разницы в скорости доступа не будет вообще. Ни там ни там нет проверок на выход за границы массива. Почти любой современный компилятор способен на это.

Есть ещё std::vector<Type>::at

Леопольд, да оптимизация практически сравнивает показатели.

И медленно. 

Тогда уж так:





Тоже штука тормозная. Хотя и безопасная.  

ну и где слив?  
в отладочной версии, без оптимизации итератор будет работать медленно, оптимизация должна свести работу с итератором к работе с простым указателем, так-как по факту, в коде должно происходить именно это,  доступ к памяти через указатель  
а вообще да, лучше пользоваться индексами, если не предполагается смена типа контейнера, потому-что если ты используешь индексы, а потом выясняется, что тебе нужно использовать не вектор, а скажем список, то придется все переписывать

Lazin, не передергивайте. Во-первых, отладочная версия и без оптимизации - совершенно разные вещи. Во-вторых изначально я и написал, что индексы выиграют если и выиграют, то чуть-чуть, а про "слив" - это ответ на совсем другое заявление одного товарища. Stl-итератор запрятывает реальную работу с указателем за слои абстракций, поэтому работа через него однозначно медленнее, это все, что я хотел сказать. Оптимизация вытаскивают его из лужи, но речь то шла не про нее.

>если ты используешь индексы, а потом выясняется, что тебе нужно использовать не вектор, а скажем список, то придется все переписывать

У stl-списка нет интерфейса доступа к объектам через индекс? Бугагашеньки:).

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