Стиль кода в циклах C (и C ++): постфиксный и префиксный приращения - PullRequest
0 голосов
/ 27 апреля 2020

В наши дни я вижу это очень часто:

for (int i = 0; i < NUMBER; ++i)

Вместо того, чтобы - как это было в моде (?) 20 лет go - это:

for (int i = 0; i < NUMBER; i++)

Есть ли причина для этого изменения, или это просто мода?

(Здесь есть похожий вопрос о Java, но я не думаю, что ответы доходят до сути вопроса)

Ответы [ 2 ]

2 голосов
/ 27 апреля 2020

Это в основном мода, но также сочетание последовательности и недопонимания.

Когда пришли итераторы, и все больше и больше людей начали понимать, что ++it может быть дешевле, чем it++, для некоторых итератор сложного, чем указатель it, они начали привыкать к прекременту везде, чтобы сохранить то, что они считают ненужными копиями в семантике постинкремента (исходное значение должно быть сохранено временно для возврата после увеличения). Затем они сделали бы это и для целых чисел, потому что почему бы и нет?

На самом деле, сохранить нечего. Ваш компилятор прекрасно способен определить, что вычисленный результат здесь никогда не используется, поэтому ++it и it++ в этом контексте имеют абсолютно идентичную семантику (если только в определении оператора не существует побочного эффекта не-идиоматизма c). ). Это особенно относится к простому целому числу i.

Конечно, это не повредит, и оно устраняет риск того, что вы пропустили какой-то странный угол, который делает привести к ненужной копии. Это хорошая практика. Просто это произошло не по необходимости.

2 голосов
/ 27 апреля 2020

C и C ++

Постинкремент включает временную задержку, которую можно избежать, используя прединкремент ( Понятие постинкремента и преинкремента? .) Тем не менее, в C ++ в основном любой объект типа класса может иметь ++ (как пост-, так и пре-), и он может быть перегружен для выполнения чего угодно. Постинкрементный большой объект имеет свою стоимость, и в зависимости от того, как реализован оператор, компилятор может не оптимизировать как постинкрементный, так и преинкрементный, чтобы делать по существу одно и то же. Для сохранения предпочтительнее использовать ++i.

20 лет a go

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...