@limelight

Здравствуйте!

Когда оформлял циклы всегда использовал такую запись:

, которая означает что цикл будет выполнен не более 10 раз, счетчик будет увеличен только после выполнения тела цикла и успешного выполнения условия(i<10).

В последнее время стал встречать другую запись: В чем принципиальное различие этих форм записей для использования цикла?
Когда какой более предпочтителен?

0

@Андрей Xomach

taras atavin, kazak, не совсем так. Для базовых типов оптимизатор (если он, конечно, у вас включен) i++ преобразует в ++i, где это возможно. Однако, для итераторов это не верно, так что есть люди, которые всегда используют ++i для сохранения целостности кода. Однако мне кажется, что i++ все-таки выглядит приятнее.

немного я опоздал с ответом)

по поводу скорости работы:
i++ в простейшем виде:
tmp = i;
++i;
return tmp;

0

@taras atavin

И это у Вас считается аргументом за идентичность операторов? Раз приходится заменять один на другой, значит они уже не равны и оптимальней тот, на который меняет оптимизатор. Причём, он ведь может быть как просто выключен, так и может потом возникнуть необходимость в замене типа на не базовый. Кроме того, сама замена отнимает время компиляции и если прогер привык писать ++i, то тем самым оптимизирует уже этот этап.

0

@sourcerer

Страуструп в цикле постоянно использует преинкремент (см. Bjarne Stroustrup - The C++ Programming Language - 2013, Fourth Edition, 9.5 Iteration Statements).

0

@taras atavin

Вот только в стандарте описаны оба оператора.

Добавлено через 5 минут
А там нечего догадываться, всё легко читается. Как раз i=i+1 заставляет гадать, что хотел ещё прикрутить к этому выражению, так как ни кто не думает в терминах "присвоить переменной i сумму i и 1", а вот "увеличить i на 1" - это как раз вполне нормальная мысль и на c++ переводится как ++i. Заметьте, не "i увеличить", а "увеличить i", то есть действие впереди операнда и чтоб их переставить в i++ нужно дополнительное время, хоть и не заметное. А неуклюжее i=i+1 читается и не вызывает необходимости догадываться только на бейсике и ему подобных языках, где инкремента нет.

0

@sourcerer

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

0

@taras atavin

Префиксный, так как постфиксный именно к нему и оптимизируется.

0

@sourcerer

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

0

@sourcerer

Согласен. Посмотрим, как же в стандарте в циклах юзают инкремент:

Миниатюры

     

0

@sourcerer

Но, в то же время:

Миниатюры

 

0

@sourcerer

Так что "по стандарту" не получится Там даже внутри циклов оба варианта используются.
Видать, в комитете по стандартизации С++ тоже любители потроллить сидят

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

0

@_Ivana

Вот ведь вопрос серьезный, как у остроконечников/тупоконечников Свифта. Если смотреть с точки зрения ассемблерного листинга, то вроде как одна бабка говорит, что префиксная эффективнее. А если забыть про эти копейки и смотреть с точки зрения стройности кода, то разработчики С (а не С++, кстати) вполне правильно сделали, придумав оба варианта, и в примерах кода применяют тот, который нагляднее отражает суть задачи - в последнем скрине пример заполнения массива по индексу, ну коряво бы выглядело начинать с -1 и делать предынкремент, гораздо стройнее смотрится начинать индекс с нуля и делать постинкремент.
ЗЫ а если счетчик еще и беззнаковый, то при предынкременте начинать надо вообще с 255 если он восьмибитный и с других чисел, если другой размер типа. И зачем с этим корячиться, если есть постинкремент?

0

@taras atavin

А какое отношение цикл имеет к стартовому индексу? Этот блок в любом случае выполняется после тела.

0

@_Ivana

Если это так, тогда это я лохЪ, поскольку не применяю предынкремент по причине моего незнания и вытекающей из него неуверенности Тогда надо вышенаписанное мной считать бредом, а мне учить предынкремент ))))

0

@John Prick

0

Jupiter

0

@numizmat

Получим.
i1= 1 i2= 1

i1= 2 i2= 1

0

@daslex

Вопрос внимательнее прочти и обрати внимание на дату...
А насчет Скотт Мейерс (More Effective c++) писал
По стандарту вообще мало что получится, если все уже не знать. Они разбросали важные кусочки по очень разным местам.

0

@Oleg Frias

опоздал)

0

@TheCalligrapher

Во-первых, у префиксного и постфиксного инкремента разная семантика результата. Первый возвращает новое значение (как lvalue), второй - старое значение (как rvalue). Поэтому в реальном коде следует выбирать именно тот вариант, который возвращает именно нужный вам результат. Это - главный критерий выбора между префиксным и постфиксным вариантами.

В-вторых, когда возвращаемое значение оператора роли не играет вообще (игнорируется), как в вышеприведенном примере с 'for', предпочтительнее применять именно префиксный вариант. В общем случае, префиксный вариант эффективнее, ибо он не требует создания копии объекта с сохраненным старым значением. Именно так, через создание копии со старым значением в общем случае реализуется постфиксный инкремент. Особо умный компилятор может уметь оптимизировать код постфиксного инкремента в ситуациях, когда результат оператора игнорируется, тем самым устраняя разницу в производительности. Но полагаться на это не стоит.

В-третьих, вышесказанные соображения эффективности применимы в первую очередь к относительно "тяжелым" пользовательским типам, и не играют роли при работе с фундаментальными типами, такими как 'int'. Тем не менее, для единообразия в С++ принято придерживаться префиксного инкремента. В языке С, где инкремент применим только к фундаментальным типам, не имеет значения, какой вариант применять (разумеется, только в ситуациях, когда вы игнорируете результат оператора).

В-четвертых, никакого "как в стандарте" тут нет и быть не может. Стандарт такими вопросам не занимается.

0

@hoggy

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

0