1. C++ / Говнокод #2321

    +67.3

    1. 1
    length=length%8==0?0:length+8-length%8;

    пытаемся округлить length до 8 в большую сторону...
    краткость - сестра ... таланта?

    Запостил: dIsoVi, 24 Декабря 2009

    Комментарии (41) RSS

    • Боюсь, что я не понимаю без контекста смысл этой записи. Но это точно, не "пытаемся округлить length до 8 в большую сторону... "
      Ответить
      • Слабо if использовать? Вот уж этот оператор ?: . Он конечно удобен, но это явно не тот случай. Он удобен, когда условие и присваемые значения очень коротки. Ещё и скобок нехватает для читабильности...
        Ответить
        • о чем и речь, лично я стараюсь вобще его не использовать, разве что за исключением случаев, когда часто встречаемая операция, то ее можно задефайнить.
          Ответить
          • Говнокодеры минусуют!!!
            Ответить
          • пиши больше таких программ, disoVi! Сайт govnokod.ru не будет пустовать!)))
            Ответить
            • каких таких? то что я привел выше не мой код.
              Ответить
              • дело не в коде, а в задефайненых операциях. Использование дефайнов позволительно только если ты пишешь под микроконтроллер и на качество кода тебе плевать. Во всех остальных случаях код с дефайнами будет практически невозможно поддерживать. Если ты не занимался большими проектами с приличным программерским, скорее всего ты будешь доказывать обратное.
                Ответить
                • окей, спс за полезный совет=) я еще токо учусь, ну и подрабатываю программистом, так что таких тонкостей не знаю)
                  Ответить
                • Какая фигня про дефайны...
                  просто меру надо знать, есть чёткая грань между тем когда надо (всё что связано с компиляцией, точно проверенные небольшие куски кода которые очень много где используются) и когда не стоит, и более того некоторые вещи очень сложно сделать с использованием функций (так как у макроса есть ##, кто не знает --- конкатенация).
                  Более того сапортинг чужой программы становится намного проще и прияытнее если не поленится расставить такие макросы как in out out_opt итд.
                  Импорт экспорт функций с использованием XXXAPI и т.д.
                  Если ты побывал в проекте в котором не умели правильно использовать макросы это не значит что макросы делают большой сложный проект тяжело сопровождаемым.

                  Единственная проблема которая может возникнуть это сложности в отладке (тк макросы пройдут за 1 шаг), но опять же в макрос нужно выносить то, что точно работает и сто раз проверено, и много где используется так что такой проблемы возникать не должно.
                  Ответить
                  • IN, OUT, XXXAPI - согласен полностью, но ведь это предефайненые макросы и введены чтобы делать код более понятным а не функциональным. То же касается RGB(r,g,b) и других подобных. Но вот функции (а тем более константы) лучше дефайнами не объявлять. Для функций есть inline, а если тебе нужна конкатенация макроязыка, то это сразу говорит о том что код будет непонятным. В отношении дефайнов-констант - самое интересное начинатся когда в проекте более одного namespace...
                    Отладка - это основная проблема и хотя бы ради нее не следует использовать дефайны. В задефайненном коде невозможно по-человечески проверить валидность (да что валидность - даже тип!) входных параметров, соответственно невозможно быть уверенным что он будет работать всегда, пусть он запускался и тестировался хоть 100 или 200 раз.
                    Насчет неумения писать дефайны несоглашусь - был умелец который очень хорошо умел их писать... и насколько я знаю до сих пор тот проект сопровождает, потому что кроме него никто не понимает
                    Ответить
    • lenght = lenght/8 + 1 ?
      Ответить
    • точнее так lenght = (int)(lenght/8) + 1 ?
      Ответить
    • в том-то и дело, что пытаемся, там ошибка есть если присмотреться) и я извиняюсь, немного неправильно написал, я имел в виду округлить до числа кратного восьми, но вобще-то по коду это итак понятно должно быть.
      Ответить
    • (x/8 + (x % 8 > 0))*8
      Ответить
    • length = (length + 7) & (~7);
      Ответить
      • Хоть один нормальный человек...
        Ответить
      • Красиво. Да. Хотя мой начальник не оценит... :(
        Ответить
        • Оценит... главное не стесняться...
          Ответить
          • Он скажет, что некрасиво и нечитабильно. Скажет, что должно быть понятно с одного взгляда на код...
            Ответить
            • "Четайте мЭтодычку" - как говорил один мой препод...
              Ответить
    • Когда я вижу, что кто-то ДЕЛИТ на степень двойки, или берёт остаток по модулю степени двойки, то это просто FFFUUUUUUUUU.
      Ответить
      • Да-а-а, читаемость при использовании шифтов и прочих побитовых радостей весьма повышает читаемость кода, ага. А Вы не думали, что *так* оптимизировать код просто не имеет смысла? А если это не попытка оптимизации, то на кой она вообще нужна?
        Ответить
        • Шо? Вы не в состоянии разобраться в "побитовых радостях"?
          И из-за таких, как вы, заставлять людей тратить деньги на новую машину?
          Зачем делать оптимально, если в лом, отмазаться от пользователей как-нибудь можно, остальное - неважно.
          Я против подобного пути развития производства, который, как зараза, залез во все сферы.
          Ответить
          • Почему-то мне кажется, что на текущий момент (канун 2010 года) такты процессора значительно дешевле времени средненького программиста, который будет разгребать Ваш "оптимальный" код. Нет, я не утверждаю, что можно, не особо напрягая мозг, клепать тематический контент данного ресурса и не думать о тормозах на стороне клиента. Я говорю лишь то, что всякой оптимизации кода существует разумный предел, переходя который, программист копает яму себе и своим коллегам.

            P.S. Все-таки в современных компиляторах реализованы качественные оптимизаторы. Кого вы обманываете, когда делаете работу за них? (а многие не раз уже убеждались, что оптимизирующие компиляторы ощутимо прозорливее большинства программистов)
            ИМХО, разумеется.
            Ответить
            • Почаще заглядывай в ассемблерный выхлоп компилятора, узнаешь много нового...
              Да, он оптимизирует, но только то что очевидно, а задача программиста подсунуть ему код который будет лучше оптимизироваться, так как какой бы крутой не был компилятор, из говна конфету он получить не в состоянии...
              Ответить
              • Это плохие компиляторы сторонних фирм. Все знают какими нужно пользоваться. Ч_Ч
                Ответить
            • Ох, минусаторы... Вот и выросло поколение, брезгующее битовыми командами.
              Кстати, о логике. Ничего, что зачастую как раз битовость логичнее? Например, чтобы извлечь красный компонент из цвета, заданного двумя байтами, логичнее не брать остаток по модулю 64, а сделать &(0x003f).
              И очень может быть, что тут ровно этот случай.
              Ответить
              • А разве я говорил, что побитовые операции - первородное Зло, которое нужно искоренять в любых проявлениях? Конкретно в Вашем примере они сами напрашиваются, я бы другого решения (не через bitwise and) и не искал. Моя мысль была в другом - желательно писать логичный код, а не жутко оптимальный. Иногда логичнее использовать побитовые операции, а иногда логично использовать именно деление, пускай оно и работает медленнее.

                P. S. Когда мне приходиться писать жутко (да-да, иногда надо) оптимальный код, я просто пихаю соответствующий логичный код в комментарии. Возможно, некрасиво и долго, но зато через месяц я (или кто-то другой) не буду мучительно думать и вспоминать, что же я делаю этим оптимальным куском кода.
                Ответить
                • деление на константу это тривиальная оптимизация, которую понимает каждый уважающий себя компилятор...
                  В данном случае можно было обойтись более простым алгоритмом, причем не затратив на это больше времени (ну разве что книжек умных надо почитать, что в любом случае делает каждый уважающий себя программист)...
                  Ответить
              • нет, поколение не брезгует битовыми командами. И то что их не используют зачастую не признак что в них ничего не понимают. Просто сейчас расставлены другие приоритеты - читабельность и прозрачность кода важнее оптимизации. Тем более, очень сомнительно что это действительно эффективная оптимизация. Сделайте профайлинг кода и вы поймете что битовые операции - это не самое узкое место у вас в коде. С вашим примером про & 0x003F я полностью согласен, но давайте взглянем правде в глаза - это один из немногих примеров, где в прикладном программировании действительно нужны. Пора выбираться из эры процессоров 8086, где программа на языке Ассемблера была много эффективней аналогичной на C.
                Ответить
          • Это всё "верования".
            Банальное деление на константу степени двойки любой вменяемый компилятор словит. Также как и перемножение. Кроме того, хорошо бы смотреть какой реальный будет выигрыш от этого в приложении. Можно экономить здесь такты, но узким местом всё равно будет вывод графики, и сколько ни вступай с арифметикой в интимные отношения, ребёночек не рождается.
            У меня коды насыщенные арифметикой не дают и капли торможения даже на бытовых машинах при переходе к "обыкновенному стилю".
            А уж если вы знаете ассемблер, а ещё лучше, если архитектуру и специфические команды машины, с которой работаете, тогда пишите машинный код в узких местах.

            Постулаты:
            1. Не оптимизируй.
            2. Если хочется оптимизировать см. правило первое.
            Ответить
            • +1
              Сейчас все нормальные компиляторы оптимизируют, а современные процессоры-числодробилки - все проглатывают и не давяться. Вот такой вот непоколибимый тандем.
              Ответить
              • Первый пункт звучал немного по другому...
                В ближайшее время принципы оптимизации опять вернутся на свои позиции, так как частота процессоров уже давно не растет, производительность процессоров за последний год выросла отсилы на проценты (2000-2001 в 2 раза)... Зато растет стоимость доступа к памяти, ...
                На консолях до сих пор на счету каждый такт и все больше появляется нетбуков и смартфонов у которых нет гигагерц и гигабайтов...
                Если 2 года назад весь рунет смеялся с индусского и китайского кода, то сейчас весь интернет смеется с русского кода... а причина очень просто, пока весь мир решает как написать так чтоб компилятор соптимизировал и процессор схавал, русские надеются, что все заработает и так... В итоге кризис почти схавал IT бизнес в СНГ...
                Ответить
                • А есть источники информации? Я бы почитал... Интересно...
                  Ответить
                  • Я работаю в большой фирме (5000 тысяч человек по всему миру - 3000 китайцев) программистом для iPhone... игры в основном крупные и требовательные...
                    ограничение: 25 метров 30 фпс - компилятор не помог ниразу...
                    Ответить
                    • Компилятор-Козёл. Не помогает...
                      Ответить
                    • Позвольте уточнить - конкретно Вы пишите больше на Objective-C, или все же на C? Просто если активно использовать возможности Objective-C, то действительно не стоит ожидать чего-либо значительного от компилятора. Пожалуй, gcc от Apple уже давно идет своей дорожкой и имеет мало общего от gcc от gcc.gnu.org (патчами они не обмениваются ввиду интересной политики Apple).
                      Ответить
                      • я пишу на С++... Objective-C (в нашем случае это Objective-C++) код составляет отсилы 5-6 файлов из 100-200 не считая библиотек, которые в большинстве случаев полностью на С++...
                        Ответить

    Добавить комментарий