- 1
length=length%8==0?0:length+8-length%8;-
C++ / Говнокод #2321
+67.3
пытаемся округлить length до 8 в большую сторону...
краткость - сестра ... таланта?Запостил:
dIsoVi,
24 Декабря 2009
Говнокод: по колено в коде.
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
© 2008-2024 «Говнокод.ру»
Обратная связь | Лицензионное соглашение | 
Follow us!
Follow us!
просто меру надо знать, есть чёткая грань между тем когда надо (всё что связано с компиляцией, точно проверенные небольшие куски кода которые очень много где используются) и когда не стоит, и более того некоторые вещи очень сложно сделать с использованием функций (так как у макроса есть ##, кто не знает --- конкатенация).
Более того сапортинг чужой программы становится намного проще и прияытнее если не поленится расставить такие макросы как in out out_opt итд.
Импорт экспорт функций с использованием XXXAPI и т.д.
Если ты побывал в проекте в котором не умели правильно использовать макросы это не значит что макросы делают большой сложный проект тяжело сопровождаемым.
Единственная проблема которая может возникнуть это сложности в отладке (тк макросы пройдут за 1 шаг), но опять же в макрос нужно выносить то, что точно работает и сто раз проверено, и много где используется так что такой проблемы возникать не должно.
Отладка - это основная проблема и хотя бы ради нее не следует использовать дефайны. В задефайненном коде невозможно по-человечески проверить валидность (да что валидность - даже тип!) входных параметров, соответственно невозможно быть уверенным что он будет работать всегда, пусть он запускался и тестировался хоть 100 или 200 раз.
Насчет неумения писать дефайны несоглашусь - был умелец который очень хорошо умел их писать... и насколько я знаю до сих пор тот проект сопровождает, потому что кроме него никто не понимает
И из-за таких, как вы, заставлять людей тратить деньги на новую машину?
Зачем делать оптимально, если в лом, отмазаться от пользователей как-нибудь можно, остальное - неважно.
Я против подобного пути развития производства, который, как зараза, залез во все сферы.
P.S. Все-таки в современных компиляторах реализованы качественные оптимизаторы. Кого вы обманываете, когда делаете работу за них? (а многие не раз уже убеждались, что оптимизирующие компиляторы ощутимо прозорливее большинства программистов)
ИМХО, разумеется.
Да, он оптимизирует, но только то что очевидно, а задача программиста подсунуть ему код который будет лучше оптимизироваться, так как какой бы крутой не был компилятор, из говна конфету он получить не в состоянии...
Кстати, о логике. Ничего, что зачастую как раз битовость логичнее? Например, чтобы извлечь красный компонент из цвета, заданного двумя байтами, логичнее не брать остаток по модулю 64, а сделать &(0x003f).
И очень может быть, что тут ровно этот случай.
P. S. Когда мне приходиться писать жутко (да-да, иногда надо) оптимальный код, я просто пихаю соответствующий логичный код в комментарии. Возможно, некрасиво и долго, но зато через месяц я (или кто-то другой) не буду мучительно думать и вспоминать, что же я делаю этим оптимальным куском кода.
В данном случае можно было обойтись более простым алгоритмом, причем не затратив на это больше времени (ну разве что книжек умных надо почитать, что в любом случае делает каждый уважающий себя программист)...
Банальное деление на константу степени двойки любой вменяемый компилятор словит. Также как и перемножение. Кроме того, хорошо бы смотреть какой реальный будет выигрыш от этого в приложении. Можно экономить здесь такты, но узким местом всё равно будет вывод графики, и сколько ни вступай с арифметикой в интимные отношения, ребёночек не рождается.
У меня коды насыщенные арифметикой не дают и капли торможения даже на бытовых машинах при переходе к "обыкновенному стилю".
А уж если вы знаете ассемблер, а ещё лучше, если архитектуру и специфические команды машины, с которой работаете, тогда пишите машинный код в узких местах.
Постулаты:
1. Не оптимизируй.
2. Если хочется оптимизировать см. правило первое.
Сейчас все нормальные компиляторы оптимизируют, а современные процессоры-числодробилки - все проглатывают и не давяться. Вот такой вот непоколибимый тандем.
В ближайшее время принципы оптимизации опять вернутся на свои позиции, так как частота процессоров уже давно не растет, производительность процессоров за последний год выросла отсилы на проценты (2000-2001 в 2 раза)... Зато растет стоимость доступа к памяти, ...
На консолях до сих пор на счету каждый такт и все больше появляется нетбуков и смартфонов у которых нет гигагерц и гигабайтов...
Если 2 года назад весь рунет смеялся с индусского и китайского кода, то сейчас весь интернет смеется с русского кода... а причина очень просто, пока весь мир решает как написать так чтоб компилятор соптимизировал и процессор схавал, русские надеются, что все заработает и так... В итоге кризис почти схавал IT бизнес в СНГ...
ограничение: 25 метров 30 фпс - компилятор не помог ниразу...