++это или это++ при переборе карты?

Для проверки я сделал три исходных файла:

#include <map>

struct Foo { int a; double b; char c; };

typedef std::map<int, Foo> FMap;

### File 1 only ###

void Set(FMap & m, const Foo & f)
{
  for (FMap::iterator it = m.begin(), end = m.end(); it != end; ++it)
    it->second = f;
}

### File 2 only ###

void Set(FMap & m, const Foo & f)
{
  for (FMap::iterator it = m.begin(); it != m.end(); ++it)
    it->second = f;
}

### File 3 only ###

void Set(FMap & m, const Foo & f)
{
  for (FMap::iterator it = m.begin(); it != m.end(); it++)
    it->second = f;
}

### end ###

После компиляции с помощью g++ -S -O3, GCC 4.6.1, я обнаружил, что версии 2 и 3 производят идентичную сборку, а версия 1 отличается только одной инструкцией, cmpl %eax, %esi против cmpl %esi, %eax.

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

it++ возвращает копию предыдущего итератора. Поскольку этот итератор не используется, это расточительно. ++it возвращает ссылку на увеличенный итератор, избегая копии.

Подробное объяснение см. в вопросе 13.15.

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

for (list<string>::const_iterator it = tokens.begin();
    it != tokens.end();
    ++it) { // Don't use it++
    ...
}

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

class MyInteger {
private:
    int m_nValue;

public:
    MyInteger(int i) {
        m_nValue = i;
    }

    // Pre-increment
    const MyInteger &operator++() {
        ++m_nValue;
        return *this;
    }

    // Post-increment
    MyInteger operator++(int) {
        MyInteger clone = *this; // Copy operation 1
        ++m_nValue;
        return clone; // Copy operation 2
    }
}

Как видите, реализация постинкремента включает две дополнительные операции копирования. Это может быть довольно дорого, если объект, о котором идет речь, громоздкий. Сказав это, некоторые компиляторы могут быть достаточно умны, чтобы обойтись одной операцией копирования посредством оптимизации. Дело в том, что пост-инкремент обычно требует больше работы, чем пре-инкремент, и поэтому разумно привыкнуть ставить ваши «++» перед вашими итераторами, а не после них.

(1) Кредит на связанный веб-сайт.

С логической точки зрения - то же самое и здесь не имеет значения.

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

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

Кроме того, на самом деле это должно быть так для любых типов вообще. Но это просто должно быть. Поскольку любой может перегрузить operator++ — постфикс и префикс, они могут иметь побочные эффекты и различное поведение.

Что ж, это ужасная вещь, но все же возможная.

Никаких проблем это не вызовет, но правильнее использовать ++it. С маленькими типами не имеет значения использование ++i или i++, но для "больших" классов:

operator++(type x,int){
    type tmp=x; //need copy
    ++x;
    return tmp;
}

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

Как уже говорилось в других ответах, предпочитайте ++ это, если оно не будет работать в контексте. Для перебора контейнеров небольших типов это действительно не имеет большого значения (или не имеет значения, если компилятор его оптимизирует), но для контейнеров больших типов это может иметь значение из-за экономии затрат на создание копии.

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