i++ против ++i, спор однако Опции

[Red Devil]

Я согласен с автором в том, что опен соурс программисты слишком непрофиссионально относятся к работе. В большенстве своем пишут на Си, те кто пишут на С++ используют его неправильно.
Стоит хотя бы исходные коды посмотреть, ужас, ужас. Естественно все будет тормозить, когда циклы не оптимизируется, пишется i++, вместо ++i, функция вызыова размерности вызывается каждый при проходе цикла, вместо того чтобы ее сохранить при начале проходе и сравнивать значение. Лишние переменные с неопределенными сроком жизни, отсуствие применения паттернов проектирования - это я его могу продолжать еще долго. Привычка пихать все в классы, ничего не разделяя. На первый взгляд кажется что типа это дело автора опен соурс, но это напрямую влияет на архитуктуру проекта и того кто будет в дальшнейшем его развивать. Большенство проектов умирают, потому что никто не хочет поддерживать тот убогий код, который был заложен автором при разработке, в том числе и сам автор.
Статью читал где-то месяц назад, про программистов во всем согласен, что там написано.

Сообщение отредактировал Red Devil - 20.7.2008, 11:29

[Red Devil]

Рискуя нарваться на крики негодования, но все же:
Инженерный подход: так, оно должно нормально работать по алгоритму M, доделаю, нужно будет еще модули X, Y, Z
Программистский подход: как же мне написать, ++i или i++? как будет быстрее?.. я выиграю 0,01мс/3 байта или нет? (спустя три часа) дада, да, я понял, ++i гораздо лучше, i++ нужно нахрен убрать из языка!

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

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

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

И дело тут не в том, что используется возращаемое значение или нет, потому что даже если оно не используется, оно все равно будет возращено и код для него отработает.

Сообщение отредактировал Red Devil - 23.7.2008, 7:38

[Tonal]

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

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

И дело тут не в том, что используется возращаемое значение или нет, потому что даже если оно не используется, оно все равно будет возращено и код для него отработает.

Я же привёл плюсовый код с совмещением (перегрузкой) инкремента, и асмовый листинг.
Покажи, пожалуйста, код, в функции f2 (в асме __Z2f21ARKS_), который отвечает за создание неиспользуемого экземпляра и его возврат.
Его нет.
Дело в том, что если у действия нет побочных эффектов, и его результат нигде не используется, его можно смело выкидывать из программы. Именно это и делает оптимизатор. Причём там всё ещё несколько сложнее, т.к. оптимизатор работает не с языковыми конструкциями, не с деревом разбора, а работает он с промежуточным объектным кодом, на уровне которого уже никакого С++ или там Ada нет - есть инструкции некоторой универсальной машины, которые потом, после оптимизации, преобразуются в объектный код.
Почитай например "Красного дракона" (Ахо А., Сети Р., Ульман Дж. Компиляторы. Принципы, технологии, инструменты)
Там всё это подробно изложено.

Это не агитация за то, чтобы убрать постинкремет из языка.
Я довольно хорошо понимаю разницу между этими операторами, и сам всегда пишу for (...; ++i).
Просто не нужно создавать мифы и догмы, нужно аккуратно пользоваться доступным инструментарием.