Считается ли инициализация итератора внутри цикла плохим стилем и почему?

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

Я серьезно сомневаюсь, что есть хоть какой-то прирост эффективности. Его также можно сделать более читабельным с помощью typedef.

typedef SomeClass::SomeContainer::iterator MyIter;

for (MyIter Iter = m_SomeMemberContainerVar.begin(); Iter != m_SomeMemberContainerVar.end(); ++Iter)
{
}

Я бы порекомендовал более короткие имена ;-)

Вы можете использовать фигурные скобки вокруг инициализации и цикла, если вас беспокоит область видимости. Часто я объявляю итераторы в начале функции и повторно использую их в программе.

Я считаю второй вариант более читаемым, так как в итоге вы не получите одну гигантскую строку. Тем не менее, Ферруччо поднимает хороший вопрос о прицеле.

Я согласен с Ферруччо. Некоторые могут предпочесть первый стиль, чтобы вывести вызов end () из цикла.

Я мог бы также добавить, что C++ 0x действительно сделает обе версии намного чище:

for (auto iter = container.begin(); iter != container.end(); ++iter)
{
   ...
}

auto iter = container.begin();
auto endIter = container.end();
for (; iter != endIter; ++iter)
{
   ...
}

Обычно я писал:

SomeClass::SomeContainer::iterator Iter = m_SomeMemberContainerVar.begin(),
                                   IterEnd = m_SomeMemberContainerVar.end();

for(...)

Если вы правильно разделите код на строки, встроенная форма будет одинаково удобочитаемой. Кроме того, вы всегда должны делать iterEnd = container.end() в качестве оптимизации:

for (SomeClass::SomeContainer::iterator Iter = m_SomeMemberContainerVar.begin(),
    IterEnd = m_SomeMemberContainerVar.end();
    Iter != IterEnd;
    ++Iter)
{
}

Обновление: исправлен код по совету паэрцебала.

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

Однако читабельность может быть проблемой; в этом можно помочь, используя typedef, чтобы тип итератора был немного более управляемым:

typedef SomeClass::SomeContainer::iterator sc_iter_t;

for (sc_iter_t Iter = m_SomeMemberContainerVar.begin(); Iter != m_SomeMemberContainerVar.end(); ++Iter)
{
}

Не большое улучшение, но небольшое.

У меня нет опыта работы с консолями, но в большинстве современных компиляторов C++ любой вариант оказывается эквивалентным, за исключением вопроса о масштабах. Компилятор Visual Studio практически всегда даже в отладочном коде помещает сравнение условий в неявную временную переменную (обычно регистр). Таким образом, хотя логически кажется, что вызов end () выполняется на каждой итерации, оптимизированный скомпилированный код на самом деле выполняет вызов только один раз, и сравнение - единственное, что выполняется каждый последующий раз в цикле.

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

Другой альтернативой является использование макроса foreach, например форсировать foreach:

BOOST_FOREACH( ContainedType item, m_SomeMemberContainerVar )
{
   mangle( item );
}

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

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

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

doStuff(coll.begin(), coll.end())

и имеют..

template<typename InIt>
void doStuff(InIt first, InIt last)
{
   for (InIt curr = first; curr!= last; ++curr)
   {
       // Do stuff
   }
 }

Что нравится:

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

Что не нравится:

• Разрушает код
• Накладные расходы на вызов дополнительной функции.

Но однажды у нас будут лямбды!

Нет, задерживать iter.end() до начала цикла - плохая идея. Если ваш цикл изменяет контейнер, то конечный итератор может стать недействительным. Кроме того, метод end() гарантированно соответствует O (1).

Преждевременная оптимизация - корень всех зол.

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

Посмотрев на это в g ++ при оптимизации -O2 (чтобы быть конкретным)

Нет никакой разницы в сгенерированном коде для std :: vector, std :: list и std :: map (и друзей). Есть крошечные накладные расходы с std :: deque.

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

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

typedef set<Apple> AppleSet;
typedef AppleSet::iterator  AppleIter;
AppleSet  apples;

for (AppleIter it = apples.begin (); it != apples.end (); ++it)
{
   ...
}

Спартанское программирование - один из способов смягчить ваши проблемы со стилем.