Использует размер () для 2-го выражения в для конструкции всегда плохо?

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

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

Затем, конечно, for может стать a while и нет никаких необходимых временных переменных вообще - можно даже передать итератор функции sumVector вместо ссылки/значения константы.

Если Вы использовали контейнер где size() был O (n) (как std::list) и не O (1) (как std::vector), Вы не выполнили бы итерации через тот контейнер с помощью индексов. Вы использовали бы итераторы вместо этого.

Так или иначе, если тело цикла так тривиально что перевычисление std::vector::size() вопросы, затем существует, вероятно, более эффективное (но возможно определенное для платформы) способ сделать вычисление, независимо от того, каково это. Если тело цикла нетривиально, повторно вычисляя std::vector::size() каждый раз вряд ли будет иметь значение.

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

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

Компилятор не будет знать, изменяется ли значение .size () между вызовами, таким образом, это не сделает никакой оптимизации. Я знаю, что Вы просто спросили об использовании .size (), но необходимо использовать итераторы так или иначе.

std::vector<double>::const_iterator iter = values.begin();
for(; iter != values.end(); ++iter)
{
    // use the iterator here to access the value.
}

В этом случае вызов к .end () подобен проблеме, которую Вы выставляете с .size (). Если Вы знаете, что цикл не выполняет операции в векторе, который делает недействительным итераторы, можно инициализировать итератор к .end (), положение до вводит цикл и использование что как граница.

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

Кроме того, если я помню правильно, некоторые компиляторы достаточно "умны", чтобы обнаружить constness выражения во второй части для конструкции и сгенерировать код, который оценивает выражение только однажды.

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

Мое предположение, что большинство компиляторов оптимизирует код в некотором смысле, тот размер () назовут только однажды. Но использование временной переменной даст Вам гарантию, размер () только назовут однажды!

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

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

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

Как небольшое в стороне, никакой компилятор не оптимизировал бы размер () к одному из присвоения вызова временному файлу. Нет почти никакой гарантии константы в C++. Компилятор не может рискнуть предполагать, что размер () возвратит то же значение для целого цикла. Например. Другой поток мог изменить вектор промежуточные повторения цикла.

Это не имеет значения вообще. Производительность наверху .at () является столь большой (это содержит условный оператор броска), что неоптимизированная версия проведет большую часть своего времени там. Оптимизирующий компилятор, достаточно умный к eliminiate, условный бросок обязательно определит тот размер (), не изменяется.

Это не часть вопроса, но почему Вы используете at в Вашем коде вместо нижнего оператора []?

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

Даже если Ваш код содержал логическую ошибку, заставляя Вас получить доступ к недопустимому элементу, at в этом месте было бы бесполезно, потому что Вы не ожидаете получающееся исключение, и следовательно Вы не рассматриваете его (или делаете Вы включаете все свои циклы try блоки?).

Использование at здесь вводит в заблуждение, потому что это говорит читателю, что Вы (как программист) не знаете то, что оценивает индекс, будет иметь – который является, очевидно, неправильным.

Я соглашаюсь с Curro, это - типичный случай для использования итераторов. Хотя это является более подробным (по крайней мере, если Вы не используете конструкции как Повышение. Foreach), это также намного более выразительно и более безопасно.

Повышение. Foreach позволил бы Вам писать код следующим образом:

double sum = 0.0;
foreach (double d, values)
    sum += d;

Эта работа безопасна, эффективна, коротка и читаема.

Стоящий замечания, что, даже если Вы имеете дело с миллионами объектов, издержки будут незначительными.

В любом случае это должно действительно быть записано с помощью итератора - поскольку там может больше наверху получать доступ к определенному примеру.

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

Если порядок повторения не важен затем, Вы могли бы всегда писать это как, который немного более эффективен.

for (int i=v.size()-1; i>=0 ;i--)
{
   ...
}

Неважно, настройки оптимизации, помещая .size () вызов во втором выражении будут самое большее так же производительны как выделение .size () вызов перед для цикла. Это:

size_t size = values.size();
for (size_t ii = 0; ii < size; ++ii) {
    sum += values.at(ii)
}

будет всегда работать, по крайней мере, а также, если не лучше, чем:

for (size_t ii = 0; ii < values.size(); ++ii) {
    sum += values.at(ii);
}

На практике, это, вероятно, вопрос привычки, начиная с выделения .size () вызов является общей оптимизацией компилятора. Однако я действительно нахожу вторую версию легче читать.

Я нахожу это еще легче, хотя:

double sum = std::accumulate(values.begin(), values.end(), 0);

Запустите с размера () в 'для' конструкции, пока Вы не должны будете оптимизировать для скорости.

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

Я соглашаюсь с Benoit. Введение новой переменной, особенно интервал или даже короткое будет обладать большим преимуществом что, называя это каждым разом.

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

Все это зависит от того, какова реализация размера вектора, насколько агрессивный компилятор и если это слушает/использует встроенные директивы.

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

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

Если бы это назовут тысячами времен, то я использовал бы временный файл.

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

Мне нелегко рассматривать то, что является рефакторингом, чтобы быть оптимизацией. Но в конце, это вроде "Вас, говорят, что помидор, я говорю помидор"...