i ++ менее эффективен, чем ++ i, как это показать?

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

Вот небольшой пример, показывающий потенциальную неэффективность постинкремента.

#include <stdio.h>

class foo 
{

public:
    int x;

    foo() : x(0) { 
        printf( "construct foo()\n"); 
    };

    foo( foo const& other) { 
        printf( "copy foo()\n"); 
        x = other.x; 
    };

    foo& operator=( foo const& rhs) { 
        printf( "assign foo()\n"); 
        x = rhs.x;
        return *this; 
    };

    foo& operator++() { 
        printf( "preincrement foo\n"); 
        ++x; 
        return *this; 
    };

    foo operator++( int) { 
        printf( "postincrement foo\n"); 
        foo temp( *this);
        ++x;
        return temp; 
    };

};


int main()
{
    foo bar;

    printf( "\n" "preinc example: \n");
    ++bar;

    printf( "\n" "postinc example: \n");
    bar++;
}

Результаты оптимизированной сборки (которая фактически удаляет вторую операцию копирования в случае постинкремента из-за RVO):

construct foo()

preinc example: 
preincrement foo

postinc example: 
postincrement foo
copy foo()

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

Конечно, хорошо иметь в виду, что пользовательский оператор ++ () - вариант до или после - может возвращать все, что хочет (или даже делать все, что хочет), и я предполагаю, что существует довольно много которые не следуют обычным правилам. Иногда мне попадались реализации, возвращающие "void", что устраняет обычную семантическую разницу.

Вы не увидите разницы с целыми числами. Вам нужно использовать итераторы или что-то еще, где post и prefix действительно делают что-то другое. И вам нужно включить все оптимизации, включить, а не выключить!

Мне нравится следовать правилу «говори то, что имеешь в виду».

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

Несколько моментов:

• Во-первых, вы вряд ли заметите существенную разницу в производительности каким-либо образом.
• Во-вторых, ваш бенчмаркинг бесполезен, если у вас отключена оптимизация. Мы хотим знать, дает ли это изменение более или менее эффективный код, а это означает, что мы должны использовать его с наиболее эффективным кодом, который может создать компилятор. Нас не волнует, быстрее ли он в неоптимизированных сборках, нам нужно знать, быстрее ли он в оптимизированных.
• Для встроенных типов данных, таких как целые числа, компилятор обычно может оптимизировать разницу. Проблема в основном возникает для более сложных типов с перегруженными итераторами приращения, когда компилятор не может тривиально увидеть, что две операции будут эквивалентны в контексте.
• Вы должны использовать код, который наиболее четко выражает ваше намерение. Вы хотите «прибавить единицу к значению» или «прибавить единицу к значению, но продолжить работу над исходным значением еще немного»? Обычно так и бывает в первом случае, и тогда предварительное приращение лучше выражает ваше намерение.

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

Этот код и комментарии к нему должны демонстрировать различия между ними.

class a {
    int index;
    some_ridiculously_big_type big;

    //etc...

};

// prefix ++a
void operator++ (a& _a) {
    ++_a.index
}

// postfix a++
void operator++ (a& _a, int b) {
    _a.index++;
}

// now the program
int main (void) {
    a my_a;

    // prefix:
    // 1. updates my_a.index
    // 2. copies my_a.index to b
    int b = (++my_a).index; 

    // postfix
    // 1. creates a copy of my_a, including the *big* member.
    // 2. updates my_a.index
    // 3. copies index out of the **copy** of my_a that was created in step 1
    int c = (my_a++).index; 
}

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

В зависимости от some_ridiculously_big_type, а также от того, что вы делаете с результатом инкремента, вы сможете увидеть разницу с оптимизацией или без нее.

В ответ Михаилу это несколько более переносимая версия его кода:

#include <cstdio>
#include <ctime>
using namespace std;

#define SOME_BIG_CONSTANT 100000000
#define OUTER 40
int main( int argc, char * argv[] ) {

    int d = 0;
    time_t now = time(0);
    if ( argc == 1 ) {
        for ( int n = 0; n < OUTER; n++ ) {
            int i = 0;
            while(i < SOME_BIG_CONSTANT) {
                d += i++;
            }
        }
    }
    else {
        for ( int n = 0; n < OUTER; n++ ) {
            int i = 0;
            while(i < SOME_BIG_CONSTANT) {
                d += ++i;
            }
        }
    }
    int t = time(0) - now;  
    printf( "%d\n", t );
    return d % 2;
}

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

Я больше не использую VC ++, поэтому я скомпилировал его (в Windows) с помощью:

g++ -O3 t.cpp

Затем я запустил его, чередуя:

a.exe   

и

a.exe 1

Мои результаты по времени были примерно одинаковыми для обоих случаев. Иногда одна версия будет быстрее на 20%, а иногда другая. Я предполагаю, что это связано с другими процессами, запущенными в моей системе.

Попробуйте использовать while или сделать что-нибудь с возвращаемым значением, например:

#define SOME_BIG_CONSTANT 1000000000

int _tmain(int argc, _TCHAR* argv[])
{
    int i = 1;
    int d = 0;

    DWORD d1 = GetTickCount();
    while(i < SOME_BIG_CONSTANT + 1)
    {
        d += i++;
    }
    DWORD t1 = GetTickCount() - d1;

    printf("%d", d);
    printf("\ni++ > %d <\n", t1);

    i = 0;
    d = 0;

    d1 = GetTickCount();
    while(i < SOME_BIG_CONSTANT)
    {
        d += ++i;

    }
    t1 = GetTickCount() - d1;

    printf("%d", d);
    printf("\n++i > %d <\n", t1);

    return 0;
}

Скомпилировано с VS 2005 с использованием / O2 или / Ox, проверено на моем настольном компьютере и на ноутбуке.

Стабильно что-то обходится на ноуте, на десктопе номера немного другие (но скорость примерно такая же):

i++ > 8xx < 
++i > 6xx <

xx означает, что числа разные, например 813 против 640 - все еще примерно на 20% ускорение.

И еще один момент - если вы замените «d + =» на «d =», вы увидите приятный трюк оптимизации:

i++ > 935 <
++i > 0 <

Однако это довольно специфично. Но ведь я не вижу причин менять свое мнение и думать, что разницы нет :)

Может быть, вы могли бы просто показать теоретическую разницу, выписав обе версии с инструкциями по сборке x86? Как многие люди указывали ранее, компилятор всегда принимает собственное решение о том, как лучше всего скомпилировать / собрать программу.

Если пример предназначен для студентов, не знакомых с набором инструкций x86, вы можете рассмотреть возможность использования набора инструкций MIPS32 - по какой-то странной причине многим кажется, что его легче понять, чем сборку x86.

Хорошо, вся эта префиксная / постфиксная "оптимизация" - это просто ... какое-то большое недоразумение.

Основная идея заключается в том, что i ++ возвращает свою исходную копию и, следовательно, требует копирования значения.

Это может быть правильным для некоторых неэффективных реализаций итераторов. Однако в 99% случаев даже с итераторами STL нет никакой разницы, потому что компилятор знает, как его оптимизировать, а фактические итераторы - это просто указатели, которые выглядят как класс. И, конечно же, нет никакой разницы для примитивных типов, таких как целые числа в указателях.

Так что ... забудь об этом.

РЕДАКТИРОВАТЬ: Очистка

Как я уже упоминал, большинство классов итераторов STL - это просто указатели, обернутые классами, все функции-члены которых встроены, что позволяет не оптимизировать такие нерелевантная копия.

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

В качестве небольшого доказательства возьмите этот код:

int sum1(vector<int> const &v)
{
    int n;
    for(auto x=v.begin();x!=v.end();x++)
            n+=*x;
    return n;
}

int sum2(vector<int> const &v)
{
    int n;
    for(auto x=v.begin();x!=v.end();++x)
            n+=*x;
    return n;
}

int sum3(set<int> const &v)
{
    int n;
    for(auto x=v.begin();x!=v.end();x++)
            n+=*x;
    return n;
}

int sum4(set<int> const &v)
{
    int n;
    for(auto x=v.begin();x!=v.end();++x)
            n+=*x;
    return n;
}

Скомпилируйте его в сборку и сравните sum1 и sum2, sum3 и sum4 ...

Я просто могу вам сказать ... gcc дает точно такой же код с -02.