MGM, Вам это пока не нужно,
photon всё правильно сказал про хороший стиль написания кода, именно такой и рекомендуют.
Скорее стиль. Это могло бы экономиться в компиляторах без оптимизатора (префиксная операция чуть проще в реализации), но вряд ли Вы с такими столкнётесь. Но ради большей совместимости могут и возвести в ранг стиля, мол "а вдруг".
Я, например, именно так и делаю: знаю, что с точки зрения производительности разницы не будет, но пишу
++j.
Ну, вообще говоря зависит от. От архитектуры, компилятора, окружения этой команды.
Вот например попробуйте для AVR написать прединкремент и постинкремент числа итераций в uint32 (такие в регистрах не хранятся) и сравнение с константой, да ещё с неоптимизирующим компилятором ... Знаете что будет? Прединкремент загрузит число в регистры (4 команды по 3 такта), увеличит его на 1 (4 команды по 1 такту), выгрузит число обратно в память (4 команды по 3 такта), вычтет константу из числа в регистрах (4 команды по такту). Постинремент же загрузит число в регистры (4 команды по 3 такта), выгрузит во временную память (4 команды по 3 такта), увеличит число в регистрах на 1 (4 команды по 1 такту), выгрузит число обратно в память (4 команды по 3 такта), загрузит число из временной памяти (4 команды по 3 такта), вычтет константу из числа в регистрах (4 команды по 1 такту). Разница в двух операциях выгрузки числа во временную память и загрузки его обратно. Но каждая операция занимает 12 тактов! Т.е. 24 лишних такта. Или 32 такта против 56 тактов. Более чем в полтора раза. Проблема разумеется в страшно медленных командах обращения в памяти, аж по 3 такта. Но уж что есть. А сохранить значение до инкремента в других регистрах (или обратно уменьшить на 1 вместо сохранения во временной памяти) плохо оптимизирующий компилятор просто не умеет.
Разумеется это с одной стороны искусственный пример, мало кто сталкивается с этим при написании кода (т.е. мало кто пишет код держа в уме возможность его применения на AVR), с другой вполне жизненный потому что (некоторые) известные компиляторы именно так себя и ведут и можно поиметь тормоза на пустом месте.
А ещё бывают безрегистровые архитектуры (один-два аккумулятора не считаем), типа PIC или STM8, в них вообще вся работа только с памятью, часто даже для однобайтовых переменных. И не везде память быстрая (за такт). И не везде результат команды сразу попадает в память (как в PIC), бывает надо его туда отправлять отдельной командой и получится почти как в AVR.
Так что в общем случае далеко не всегда производительность одинакова.
А то привыкли все к компам с
хорошо оптимизирующими компиляторами и огромными кэшами и суперскалярностью с отдельными портами загрузки/выгрузки, понапишут библиотек абы как, а потом пытаешься их использовать не на компе - и получаешь страх и ужас, особенно если посмотришь в бинарный код после компилятора ... Я вообще зарёкся туда смотреть пока программы не слишком тормозят - моментально возникает желание переписать вообще весь этот кошмар на асме (что разумеется глупость, но иногда таки приходится, хотя бы частично, особенно обработчики прерываний).
Другое дело что все эти тонкости всплывают обычно уже в около-профессиональной деятельности, когда приходится максимально ужиматься по ресурсам контроллера (цене, току потребления, размеру кода и используемого ОЗУ, ...), при работе же только с компами (ну и мобильниками теперь уж) и с обычными приложениями (где не надо выжимать каждый десяток процентов скорости) на любую разницу такого порядка можно смело плевать.
Но вообще Вы делаете всё правильно, совершенно Вам не возражаю, именно такой стиль и рекомендуют уже относительно давно. Не из-за производительности, а ради уменьшения ошибок человека.
