http://cplus.about.com/od/beginnerctutorial/l/aa101302f.htm


получаеncя в конструкции типа этого i++ делать накладно или в STL/boost такое работает по другому ?

    vector<int> lst;
    lst.push_back(1); lst.push_back(2); lst.push_back(3);
    vector<int>::iterator i = lst.begin();
    vector<int>::iterator j = lst.begin();

    for( ; j != lst.end(); ++j ){ putchar(*j); }
    for( ; i != lst.end(); i++ ){ putchar(*i); }

Lepsik wrote:
> http://cplus.about.com/od/beginnerctutorial/l/aa101302f.htm
>
>
> получаеncя в конструкции типа этого i++ делать накладно или в STL/boost такое работает по другому ?

Да, при постфиксном инкременте/декременте выполняется два копирования
(при конструирование временного объекта, внутри оператора и при возврате
из оператора).

Здравствуйте, Lepsik, Вы писали:

L>получаеncя в конструкции типа этого i++ делать накладно или в STL/boost такое работает по другому ?
В данном конкретном случае, на типичном оптимизирующем компиляторе, после inline-подстановок разницы не будет. Тем не менее, многие считают первый вариант (с преинкрементом) более выразительным с точки зрения семантики.
Вообще, если настолько тревожат накладные расходы, то более подходящий вариант будеть выглядеть так:

  vector<int> lst;
  lst.push_back(1); lst.push_back(2); lst.push_back(3);
  vector<int>::iterator i( lst.begin( ) ), i_end( lst.end( ) );
    
  for( ; i != i_end; ++i ){ putchar(*i); }

Это может удивить , но врядли хоть одна программа на свете решила свои проблемы с производительностью , за счет использования ++i вместо i++. А сатеру с сотоварищами могу посоветовать только заниматься более практически полезными аспектами.

L>получаеncя в конструкции типа этого i++ делать накладно или в STL/boost такое работает по другому ?

L>

L>    vector<int> lst;
L>    lst.push_back(1); lst.push_back(2); lst.push_back(3);
L>    vector<int>::iterator i = lst.begin();
L>    vector<int>::iterator j = lst.begin();

L>    for( ; j != lst.end(); ++j ){ putchar(*j); }
L>    for( ; i != lst.end(); i++ ){ putchar(*i); }
L>

Я бы написал так:

    vector<int>::iterator i = lst.begin();

    while(i != lst.end()) { putchar(*i++); }

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

Здравствуйте, Lepsik, Вы писали:

L>http://cplus.about.com/od/beginnerctutorial/l/aa101302f.htm


L>получаеncя в конструкции типа этого i++ делать накладно или в STL/boost такое работает по другому ?

L>

L>    vector<int> lst;
L>    lst.push_back(1); lst.push_back(2); lst.push_back(3);
L>    vector<int>::iterator i = lst.begin();
L>    vector<int>::iterator j = lst.begin();

L>    for( ; j != lst.end(); ++j ){ putchar(*j); }
L>    for( ; i != lst.end(); i++ ){ putchar(*i); }
L>

ИМХО лучше такие конструкции в STL вообще не использовать, без крайней необходимости.

std::for_each(lst.begin(),lst.end(),ptr_fun(putchar));

Или свой функтор написать.
А с ++i или i++ заморачиваться, только когда свой алгоритм делаешь.

Здравствуйте, minorlogic, Вы писали:

M>Это может удивить , но врядли хоть одна программа на свете решила свои проблемы с производительностью , за счет использования ++i вместо i++. А сатеру с сотоварищами могу посоветовать только заниматься более практически полезными аспектами.

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

Использование преинкремента в случае, когда предыдущее значение не используется, правильнее не только с точки зрения семантики. Зачем создавать лишний ненужный объект, надеясь, что оптимизатор его удалит? Лучше его не создавать, тем более, что это ничего не стоит: i++ или ++i.

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

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

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

Здравствуйте, Dmitry Kotlyarov, Вы писали:

DK>Слишком категоричное утверждение, чтобы с ним можно было согласиться.

Как человек професионально занимающийся оптимизацией, я свою точку зрения высказал — проблема высосана из пальца.

еще раз.
1. Я не спорю что постинкремент в некоторых ситуациях может быть медленее.

2. Я лишь хочу сказать если человек уделяет этому внимание — он борется с ветряными мельницами, и скорее всего и представления не имеет о том как пишутся быстрые программы.

в общем посмотрел что оптимизатор делает в VS8 — он просто i++ меняет на ++i — в общем думать много не надо


MTP>В данном конкретном случае, на типичном оптимизирующем компиляторе, после inline-подстановок разницы не будет. Тем не менее, многие считают первый вариант (с преинкрементом) более выразительным с точки зрения семантики.
MTP>Вообще, если настолько тревожат накладные расходы, то более подходящий вариант будеть выглядеть так:
MTP>[ccode]
MTP> vector<int> lst;
MTP> lst.push_back(1); lst.push_back(2); lst.push_back(3);
MTP> vector<int>::iterator i( lst.begin( ) ), i_end( lst.end( ) );

Здравствуйте, minorlogic, Вы писали:

M>Как человек професионально занимающийся оптимизацией, я свою точку зрения высказал — проблема высосана из пальца.
M>еще раз.
M>1. Я не спорю что постинкремент в некоторых ситуациях может быть медленее.
M>2. Я лишь хочу сказать если человек уделяет этому внимание — он борется с ветряными мельницами, и скорее всего и представления не имеет о том как пишутся быстрые программы.

А этому и не надо уделять внимание, надо просто иметь это в виду.

Если честно, не совсем понимаю предмет спора. На мой взгляд, понимание того, что скорость работы постинкремента зависит от возможностей оптимизатора (в т.ч. в конкретном месте кода) и скорости работы конструктора, не помешает разработчику на C++. И раз уж человек интересуется этим, зачем говорить ему: "Забей, это тебе вряд ли пригодится."? Речь-то в данном случае идет не об оптимизации, а о понимании тонкостей C++.

Здравствуйте, Dmitry Kotlyarov, Вы писали:

...
Речь-то в данном случае идет не об оптимизации, а о понимании тонкостей C++.

Ну тогда , совсем другое дело.

поиск рулит

i++ VS ++i

Автор: Vadimmer
Дата: 09.05.06