- 1
length=length%8==0?0:length+8-length%8;
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+67.3
length=length%8==0?0:length+8-length%8;
пытаемся округлить length до 8 в большую сторону...
краткость - сестра ... таланта?
guest 24.12.2009 06:45 # 0
guest 24.12.2009 08:10 # 0
dIsoVi 24.12.2009 08:42 # −3
guest 24.12.2009 21:58 # −2
guest 25.12.2009 16:11 # −1
guest 25.12.2009 16:13 # 0
explosion_head 29.12.2009 12:07 # +1
dIsoVi 29.12.2009 12:51 # 0
guest 30.12.2009 17:15 # +2
просто меру надо знать, есть чёткая грань между тем когда надо (всё что связано с компиляцией, точно проверенные небольшие куски кода которые очень много где используются) и когда не стоит, и более того некоторые вещи очень сложно сделать с использованием функций (так как у макроса есть ##, кто не знает --- конкатенация).
Более того сапортинг чужой программы становится намного проще и прияытнее если не поленится расставить такие макросы как in out out_opt итд.
Импорт экспорт функций с использованием XXXAPI и т.д.
Если ты побывал в проекте в котором не умели правильно использовать макросы это не значит что макросы делают большой сложный проект тяжело сопровождаемым.
Единственная проблема которая может возникнуть это сложности в отладке (тк макросы пройдут за 1 шаг), но опять же в макрос нужно выносить то, что точно работает и сто раз проверено, и много где используется так что такой проблемы возникать не должно.
explosion_head 31.12.2009 12:49 # −1
Отладка - это основная проблема и хотя бы ради нее не следует использовать дефайны. В задефайненном коде невозможно по-человечески проверить валидность (да что валидность - даже тип!) входных параметров, соответственно невозможно быть уверенным что он будет работать всегда, пусть он запускался и тестировался хоть 100 или 200 раз.
Насчет неумения писать дефайны несоглашусь - был умелец который очень хорошо умел их писать... и насколько я знаю до сих пор тот проект сопровождает, потому что кроме него никто не понимает
guest 05.01.2010 09:46 # −1
guest 24.12.2009 08:35 # −1
guest 24.12.2009 08:36 # −1
dIsoVi 24.12.2009 08:38 # 0
WGH 24.12.2009 12:48 # −1
pushkoff 24.12.2009 18:51 # +4
TarasB 24.12.2009 20:12 # +1
guest 24.12.2009 22:16 # 0
pushkoff 25.12.2009 11:32 # 0
guest 25.12.2009 20:42 # 0
pushkoff 25.12.2009 21:19 # 0
guest 25.12.2009 22:53 # 0
TarasB 24.12.2009 20:12 # +1
guest 24.12.2009 20:39 # +2
TarasB 24.12.2009 21:15 # −1
И из-за таких, как вы, заставлять людей тратить деньги на новую машину?
Зачем делать оптимально, если в лом, отмазаться от пользователей как-нибудь можно, остальное - неважно.
Я против подобного пути развития производства, который, как зараза, залез во все сферы.
guest 24.12.2009 23:56 # +2
P.S. Все-таки в современных компиляторах реализованы качественные оптимизаторы. Кого вы обманываете, когда делаете работу за них? (а многие не раз уже убеждались, что оптимизирующие компиляторы ощутимо прозорливее большинства программистов)
ИМХО, разумеется.
pushkoff 25.12.2009 12:01 # 0
Да, он оптимизирует, но только то что очевидно, а задача программиста подсунуть ему код который будет лучше оптимизироваться, так как какой бы крутой не был компилятор, из говна конфету он получить не в состоянии...
guest 25.12.2009 20:44 # 0
pushkoff 25.12.2009 21:22 # −1
TarasB 26.12.2009 15:35 # +1
Кстати, о логике. Ничего, что зачастую как раз битовость логичнее? Например, чтобы извлечь красный компонент из цвета, заданного двумя байтами, логичнее не брать остаток по модулю 64, а сделать &(0x003f).
И очень может быть, что тут ровно этот случай.
guest 26.12.2009 17:05 # +1
P. S. Когда мне приходиться писать жутко (да-да, иногда надо) оптимальный код, я просто пихаю соответствующий логичный код в комментарии. Возможно, некрасиво и долго, но зато через месяц я (или кто-то другой) не буду мучительно думать и вспоминать, что же я делаю этим оптимальным куском кода.
pushkoff 26.12.2009 17:30 # 0
В данном случае можно было обойтись более простым алгоритмом, причем не затратив на это больше времени (ну разве что книжек умных надо почитать, что в любом случае делает каждый уважающий себя программист)...
explosion_head 29.12.2009 12:17 # +1
interested 25.12.2009 14:08 # 0
Банальное деление на константу степени двойки любой вменяемый компилятор словит. Также как и перемножение. Кроме того, хорошо бы смотреть какой реальный будет выигрыш от этого в приложении. Можно экономить здесь такты, но узким местом всё равно будет вывод графики, и сколько ни вступай с арифметикой в интимные отношения, ребёночек не рождается.
У меня коды насыщенные арифметикой не дают и капли торможения даже на бытовых машинах при переходе к "обыкновенному стилю".
А уж если вы знаете ассемблер, а ещё лучше, если архитектуру и специфические команды машины, с которой работаете, тогда пишите машинный код в узких местах.
Постулаты:
1. Не оптимизируй.
2. Если хочется оптимизировать см. правило первое.
guest 25.12.2009 20:46 # −1
Сейчас все нормальные компиляторы оптимизируют, а современные процессоры-числодробилки - все проглатывают и не давяться. Вот такой вот непоколибимый тандем.
pushkoff 25.12.2009 21:44 # +1
В ближайшее время принципы оптимизации опять вернутся на свои позиции, так как частота процессоров уже давно не растет, производительность процессоров за последний год выросла отсилы на проценты (2000-2001 в 2 раза)... Зато растет стоимость доступа к памяти, ...
На консолях до сих пор на счету каждый такт и все больше появляется нетбуков и смартфонов у которых нет гигагерц и гигабайтов...
Если 2 года назад весь рунет смеялся с индусского и китайского кода, то сейчас весь интернет смеется с русского кода... а причина очень просто, пока весь мир решает как написать так чтоб компилятор соптимизировал и процессор схавал, русские надеются, что все заработает и так... В итоге кризис почти схавал IT бизнес в СНГ...
guest 25.12.2009 22:54 # +1
pushkoff 26.12.2009 00:44 # 0
ограничение: 25 метров 30 фпс - компилятор не помог ниразу...
guest 26.12.2009 10:28 # 0
guest 26.12.2009 16:50 # 0
pushkoff 26.12.2009 16:58 # 0