[12066] Optimize some parts for ++C

[newsbot]

Автор: stfx

m src/game/AchievementMgr.cpp

m src/game/BattleGround.cpp

m src/game/BattleGroundAV.cpp

m src/game/BattleGroundMgr.cpp

m src/game/CalendarHandler.cpp

m src/game/CellImpl.h

m src/game/Chat.cpp

m src/game/Corpse.cpp

m src/game/CreatureEventAI.cpp

m src/game/CreatureEventAIMgr.cpp

m src/game/DBCStores.cpp

m src/game/GameEventMgr.cpp

m src/game/Item.cpp

m src/game/Level2.cpp

m src/game/Level3.cpp

m src/game/MapPersistentStateMgr.cpp

m src/game/ObjectMgr.cpp

m src/game/PathFinder.cpp

m src/game/Pet.cpp

m src/game/Player.cpp

m src/game/PlayerDump.cpp

m src/game/QueryHandler.cpp

m src/game/ReputationMgr.cpp

m src/game/SocialMgr.cpp

m src/game/Spell.h

m src/game/SpellAuras.cpp

m src/game/SpellAuras.h

m src/game/SpellEffects.cpp

m src/game/SpellMgr.cpp

m src/game/Transports.cpp

m src/game/WaypointManager.cpp

m src/game/vmap/BIH.cpp

m src/game/vmap/BIH.h

m src/game/vmap/TileAssembler.cpp

m src/mangosd/CliRunnable.cpp

m src/mangosd/soapC.cpp

m src/realmd/PatchHandler.cpp

m src/shared/Auth/BigNumber.cpp

m src/shared/Database/DBCFileLoader.cpp

m src/shared/Database/DatabaseMysql.cpp

m src/shared/Database/DatabasePostgre.cpp

m src/shared/Database/QueryResultMysql.cpp

m src/shared/Database/QueryResultPostgre.cpp

m src/shared/Database/SqlOperations.cpp

m src/shared/ProgressBar.cpp

m src/shared/ServiceWin32.cpp

m src/shared/WheatyExceptionReport.cpp

m src/shared/revision_nr.h

[12066] Optimize some parts for ++C

Подробнее...

[Sid]

Опять двадцать пять? Кто-то н те же грабли наступает, кто там у руля на мангосе?))

[LordJZ]

Просто некоторым этот беспричинный i++ мозолит глаз. Я из их числа.

[zergtmn]

экономия на спичках

[Vladimir]

просто кривой код

Чем бы дитя не тешилось Главное чтобы в циклах типа for таким не страдали, бо мозоль в глазах может неожиданно превратиться в геморой на заднице при смене компилятора
И если i++ это кривой код( Опять таки кривой для какого компилятора? Для VS? ), то какими словами тогда описать реализацию классов, их наследование и вобще доступ к ним в мангосе?

[Vladimir]

i++ в for показывает отсутствие у кодера базовых представлений в чем разница у prefix/postfix оператора ++ и как работает конструкция for на самом деле. С классами и наследование обычно все сложнее - это компромисс обычно между красотой, текущим способом использования, промежуточным состояние перехода от одной структуры классов к другой и т.д, так как большая часть кода существует очень долго и даже со времени когда и мангоса еще не было. В отличие от этого для неправильного использования ++ просто нет обоснований кроме плохого знания языка кодером или глупой привычки пришедшей из древних времен C.

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

Я никому ничего не указывал.
Володя, чисто напоорать в чем разница между строками:
i++ и ++i?
По правилам в первом случае будет увеличение, а потом присвоение.
Во втором случае будет присвоение, а потом увеличение.
Вопрос только в том как это дело обрабатывает компилятор. Опускает он в первом случае присваивание или нет, хотя во втором случае точно так же можно опустить присваивание при переводе этого всего в машинный код какой-нибудь add eax 1 и тогда разницы аж никакой. И тут не вопрос в знании языка. Ибо язык это стандарт. А вот как твой код с С++ переводится в машинный код, это уже компилятор, а не знание языка, а это уже совершенно другая песня.

По классам. Вот поэтому и смешно. Что ++i и i++ это плохо, при этом я уже понял, что в компиляторах никто не разбирался ни в мелкосовтовском ни в g++. А то что классы просто ужасно реализованы, причем ни один из перечисленых тобой компромисов, их реализация и использование не подпадает абсолютно под твое описание, это нормально. И да... обычно, чтобы небыло "перехода структыры классов" обычно перед тем как их писать долго думают о реализации. Но это все лирика для бедных.

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

http://habrahabr.ru/post/113661/ Вот, Владимир, почитай на досуге. VS 2008 давно сама оптимизирует это. Дебаг правда ещё нет, но *** дебага такая мега оптимизация нафиг не нужна.
В GCC это вобще давным давно все есть.
Вывод прежний

[Forgotten]

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

[Vladimir]

И да... обычно, чтобы небыло "перехода структыры классов" обычно перед тем как их писать долго думают о реализации.

Основные классы в мангос существуют с до-мангосовских времен. И поверьте, они гораздо более чистые сейчас чем были изначально. Куча всего вынесена в отдельные специализированные классы и т.д. Я убежденные сторонник того что при правильном подходе неудачные решения в архитектуре программы можно эволюционно перевести в более удачные в ходе рефакторинга, а также 100% уверен что невозможно сразу продумать идеальную структуру классов и т.д. - хотя бы потому что в реальности постоянно меняются требования к программе в процессе ее разработки. И очень редко девелопер что-то делает с чистого листа - чаще у него есть некий код написанный кем-то еще и надо его исправлять, развивать и подгонять к новым требованиям.

http://habrahabr.ru/post/113661/ Вот, Владимир, почитай на досуге. VS 2008 давно сама оптимизирует это. Дебаг правда ещё нет, но *** дебага такая мега оптимизация нафиг не нужна.

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

[LordJZ]

Сообщение от Vladimir

просто кривой код

Сообщение от Vladimir

i++ в for показывает отсутствие у кодера базовых представлений в чем разница у prefix/postfix оператора ++ и как работает конструкция for на самом деле.
...
В отличие от этого для неправильного использования ++ просто нет обоснований кроме плохого знания языка кодером или глупой привычки пришедшей из древних времен C.

Не согласен. Может быть наоборот. Например, Visual Studio вставляет сниппет цикла for с постфиксным инкрементом/декрементом, и разработчик, зная, что разница между «int i; ++i;» и «int i; i++;» не стоит внимания, не бежит исправлять оператор за пару строк и сотню символов.