@alexbmd

почему for обнуляет вместо того чтобы присвоить ?

0

@Azazel-San

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

0

@TheCalligrapher

Это откуда вы взяли такую странную информацию??

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

1

@alexbmd

а если результат участвует в дальнейших вычеслениях и оптимизации компилятора отключенны то разница так понимаю будет ?

0

@TheCalligrapher

Зависит от этих "дальнейших вычислений". Правило тот простое: используйте именно тот оператор, который нужен в данном контексте. А компилятор уже сам разберется, как сгенерировать оптимальный код.

Таки вещи никак не зависят от включенных или выключенных "оптимизаций компилятора".

0

@Azazel-San

alexbmd, вы не увидите разницы ни при каких-либо явно включённых оптимизациях, ибо для фундаментальных типов инкремент (+1) выполнит процессор и здесь не может быть никаких отличий.
Например возьмём цикл for (int i = 0; i < 10000; i++), здесь операция i++ хорошо определена и нам точно известен порядок вычисления по отношению к остальным выражениям, до и после i++ и в любом случае все что здесь нам надо это увеличить i на 1 и именно это мы всегда получим в сгенерированном коде, внезависимости от того будет ли это постфиксный или префиксный инкремент.
Более того в некоторых случаях в циклах префиксный инкремент может ввести зависимость от данных в ваш код

0

@zayats80888

А можно поподробнее(или ссылку)?

0

@Azazel-San

zayats80888, Game Engine Architecture (3rd edition), там есть топик посвящённый этому.

0

@alexbmd

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

Azazel-San, ну вот for плохой пример для этого. тут разницы нету и так и так
for(;;++i) print i
for(;;i++) print i
//результат одинаковый

хотя бы вот
for(;++i; ) print i
for(;i++; ) print i
//тут я думал может получиться разный код (ну только более сложный пример нужен конечно). но нет так нет

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

0

@zayats80888

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

Добавлено через 2 минуты
Ну вот открыл библиотеку <algorithm> и вижу в арифметике итераторов везде префиксный инкремент/декремент(если явно не требуется постфиксный) Ну и книжка Страуструпа приучила меня к такомуже подходу, а он то уж точно не "сишник"

0

@Azazel-San

Допустим у нас есть такой код:
В примере process_array() мы используем постинкрементный оператор, p++. Это тонкая, но иногда важная оптимизация. Оператор preincrement увеличивает содержимое переменной до того, как ее (теперь измененное) значение используется в выражении. Оператор postincrement увеличивает содержимое переменной после ее использования. Это означает, что написание ++p вводит зависимость данных в ваш код - CPU должен дождаться завершения операции инкремента, прежде чем его значение можно будет использовать в выражении. На глубоко конвейерном процессоре, это приводит к остановке. С другой стороны, с p++ нет зависимости. Значение переменной можно использовать немедленно, а операция приращения может произойти позже или параллельно с ее использованием.
Конечно, в выражении «update» цикла for не должно быть различий между пре- и постинкрементами. Это потому, что любой хороший компилятор распознает, что значение переменной не используется в update_expr. Но в тех случаях, когда используется значение, постинкремент предпочтительнее, поскольку он не приводит к задержке в конвейере CPU.
Может быть целесообразно сделать исключение из этого небольшого практического правила для классов с перегруженными операторами приращения, как это принято в классах итераторов. По определению оператор постинкремента должен возвращать неизмененную копию объекта, для которого он вызывается. В зависимости от размера и сложности элементов данных класса, дополнительная стоимость копирования итератора может склонить шкалы к предпочтению преинкремента при использовании таких классов в циклах, критичных к производительности

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

1

@zayats80888

правильно ли я понял, что в данном случае оптимизация в том, что постинкремент выполняется не в конце итерации а в начале? Т. е. p!=end->p++-><тело цикла, работаем с значением p до инкремента>?

0

@Azazel-San

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

1

@alexbmd

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

Добавлено через 9 минут
Azazel San мы в обоих случаях работаем с одинаковым значением.

p=0;
p!=end -> p++ -> print p//0 -> p=1 -> p!=end ->
p!=end -> ++p -> print p//0 -> p=1 -> p!=end ->

вот и Калиграфер говорит
"Третий сегмент из заголовка for выполняется в конце каждой итерации."

ну там понятно разница в инкременте есть, но в теле лупа оно нам не видно

PS: не спора ради а просветления для

0

@Azazel-San

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

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

Добавлено через 1 минуту

0

@zayats80888

я подумал что то вроде этого, например
p!=end->p++-><тело цикла, работаем с значением p до инкремента>->p!=end->(т.к. p уже прирастили можно не ожидать, а сразу в тело нырять, где-нибудь параллельно опять прирастим)<тело цикла, работаем с увеличенным в прошлый раз значением p>->(если не прирастили, ожидаем) и т.д.

0

@Azazel-San

zayats80888, смотрите, вот ключевые фразы:
Здесь может быть немного запутанно, что имеет ввиду автор, но вот как иногда описывают цикл for:
update_expr - это именно так секция где идет обновление счетчика, обычно мы его хотим видеть в последнем блоке цикла, но это не всегда так, в примере выше я тоже его разместил в конце, просто из-за удобства.
И вот если это значение update не используется выхлоп будет одинаковым.

И это:
Когда же приходит тот момент использования?
Например в чем-то таком:

1

@zayats80888

0

@Azazel-San

Весьма не удачный пример, т.к. обращение к массиву компилятор всеравно может выкинуть
Вот, например что-то такое
https://godbolt.org/z/NEYHpe
Да, вероятно имеет, результат постинкремента можно использовать и параллельно на другом конвейере инкремент выполнить.
Опять же, нужно смотреть конкретный asm-код.

Может, ув. TheCalligrapher, пролил бы свет

1

@Kuzia domovenok

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

0

@TheCalligrapher

Нет, разумеется. Никакого смысла в такой оптимизации для инкремента скалярного типа нет.

0