Все советуют добавлять единицу вот так ++i, но такой способ на мой взгляд совершенно не читабелен. Неудобно мне и все тут. Скажите, насколько хуже вариант i++? В чем принципиальная разница?
Где-то я читал, что при i++ создаются дополнительные объекты и вообще этот вариант больше ПВ отнимает... Тоже интересно.
разница будет, когда будешь использовать присваивания Код (Text): int x = i++; или циклы типа Код (Text): while(i--) { ... }
Как раз, очень читабелен, потому что понятно, что происходит - увеличение или высчитывания значения с последующим увеличением; просто ты уже привык. Разница принципиальна и заключается в том, что ++i - это префиксный инкремент, а i++ - постфиксный. При использовании постфиксного, состояние объекта до инкремента/декремента сохраняется, поэтому компилятор может сгенерить код, в котором состояние объекта реально будет сохраняться, например, в стеке, хотя у меня пример такой ситуации по-быстрому воссоздать не получилось. Вобщем, пишите "правильно": для того, чтобы увеличить значение переменной на единицу правильнее использовать префиксный ++i.
если просто прибавлять единицу то без разницы, но если применяется в выражениях то разница очевидна: j = ++i; не аналогично j = i++; для встроенных типов оптимизация нормально отработает. Для объектов все немного не так, если для префиксного оператора можно возвращать ссылку, то для постфиксного, чтобы соответствовать встроенным операторам, необходимо перед инкрементом создавать временный объект и возвращать его по значению.
Оптимизация конкретного компилятора никак не может являться аргументом в пользу неправильного использования операторов языка)
Lunar_ Где не правильное использование? Если не использовать в выражениях, а просто прибавлять единицу, то Код (Text): i++; будет полностью эквивалентно Код (Text): ++i; Причём здесь конкретные компиляторы?
Вся разница ++i или i++ становится очевидна на достаточно весомых итераторах. i++ создаёт дополнительные расходы на создание копии объекта в стеке. На int в плане траты ресурсов разницы никакой нет.
сколько видел, i++ просто преобразовывалось в 2 операции - i и i += 1. это для простых типов. а если как оператор пользовательских классов, то тут как создатель его намудрит.
В _чем_ оно эквивалентно? В сгенерированом коде? Я говорю о стиле вообще, а не о конкретном примере в конкретном случае. Не стоит писать оператор постфиксного присваивания там, где исходя из задачи надо использовать префиксный, даже если на работу программы это не повлияет. Примерно так же, как не стоит включать лишние заголовки в исходный код, хотя он и с ними и без них одинаково будет компилироваться, в чём разница ? Как пример можно привести ситуацию, когда придется изменить тип int на какой-нибудь сложный тип, описаный классом (что-то дробное и хитрое, к примеру).
Разница конечно есть, если прочесть описание оператора. Но не одного компилятора который бы создавал дополнительную переменную (с простыми типами) в релизе я не видел. Что на счет "не читабельности" то не вижу особых проблем с этим, просто дело привычки... И я не понимаю чем принципиально постфиксный оператор от префиксного в С++ так отличается вроде он такой же как и в С. Еcтm подозрение что конструкция вида volatile int i=0; ....i++) будет лишний раз сохранять переменную, но проверять это лень) P.S. сам пишу ++i))) мне больше нравится.
2h0t как выше писал, отличается, тем что возможна перегрузка оператора для класса. И в силу описанных причин, будет дополнительно вызыватся конструктор копирования два раза и деструктор, тк объект нужно будет возвращать по значению. >> будет лишний раз сохранять переменную, но проверять это лень будет всегда сохранять, но оптимизирующие компиляторы это всегда прочекают для встроенных типов. Но как справедливо заметил Lunar_ есть ещё до жопы говнокомпиляторов (tcc, lcc и тд) которые вообще не имеют оптимизации и сгенерят тебе тонну гкода.
h0t, ты просто мыслишь то, что получится в результате, а мы уже обсуждали то, как правильно само по себе) Гармония, блин..)
Lunar_ Если не использовать в выражениях, то можно использовать оба варианта, и слово "надо" здесь не приемлемо. Да, если для вашего компилятора не эквивалентно - используйте другой компилятор. Поясните пожалуйста, что это за такой стиль вообще. Разница в лишних строчках кода.
qwe8013 а когда вдруг из i++ она превратится в более сложную конструкцию, вы будете не просто дописывать "x =" ,а еще и исправлять с какой стороны ++? что же очень "рационально".
И как часто у тебя i++ внутри for() превращается в более сложную конструкцию, ещё и с оператором присваивания?
ОМГ, друзья, при всём уважении: вы пытаетесь поспорить о фигне какой-то, ИМХО. Есть язык С. Есть вполне понятное правило: там, где надо увеличить переменную на 1 - пиши ++переменная, а там, где надо сначала взять значение, а потом и увеличить - пиши переменная++. При чем тут компиляторы и какой код они генерят в конкретных случаях ? При чем тут то, что в какой-то конкретной ситуации нет разницы как писать - "превед" или "привет", всё равно вас поймут ? Если хотите настоящий пример, почему не надо игнорировать правила языка - вот вам пример: у меня перемнная i типа int превращается в процессе рефакторинга в переменную типа MyInt. и имеем варнинг Будете доказывать, что от наличия варнингов в моём компиляторе сгенерированый в этом случае код не изменится, ударяясь в какой-то такой "антиэстетизм" ? cppasm, а почему обязательно внутри for() ? О for() речи не было нигде.