1. Си / Говнокод #4902

    +141

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    18. 18
    19. 19
    20. 20
    21. 21
    22. 22
    23. 23
    static int16_t have_upper_dot(cell *c)
    {
     cell *cc;
     int16_t H;
     H=my_bases.ps;
     cc=c->prev;
     if ((cc->flg & c_f_dust) &&
          (c->w>4 && cc->h>=2 && cc->w>=2 &&
    	(abs(cc->h-cc->w)<=H/6 || cc->h<cc->w && cc->w-cc->h<=H/4) &&
    	cc->col+1>=c->col && cc->col+cc->w-5<=c->col+c->w ||
           c->w<=4 && abs(c->col-cc->col+(c->w-cc->w)/2)<=2) &&
          cc->row+cc->h-2<=my_bases.b2)
       return 1;
     cc=c->next;
     if ((cc->flg & c_f_dust) &&
          (c->w>4 && cc->h>=2 && cc->w>=2 &&
    	(abs(cc->h-cc->w)<=H/6 || cc->h<cc->w && cc->w-cc->h<=H/4) &&
    	cc->col+1>=c->col && cc->col+cc->w-5<=c->col+c->w ||
           c->w<=4 && abs(c->col-cc->col+(c->w-cc->w)/2)<=2) &&
          cc->row+cc->h-2<=my_bases.b2)
       return 1;
     return 0;
    }

    Из одной OCR программы.

    Запостил: f0ma, 12 Декабря 2010

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

    • В этом C так много c
      Ответить
    • показать все, что скрыто> cc=c->prev

      Что же может означать последовательность символов "->" в языке С... Наверное, это "минус больше". То есть из cc вычитается число, большее чем prev. Да, наверное, так и есть. Очень полезный оператор.
      Ответить
      • обращение к значению , а не ссылке же
        Ответить
      • Паскаль:
        a <> b
        Как же это. Наверное, a меньше b, и, одновременно, b меньше a. Или даже a меньше, чем больше b.
        Какой полезный оператор.
        Ответить
        • <= меньше или равно.
          => больше или равно.
          По логике тогда <> меньше или больше.
          Почему в Си используется !=, но нет !< и !> — ведь это было бы так логично?
          => и <= — это импликация. Матан-наци негодует!
          Ответить
          • <> - более-менее :)
            Ответить
          • А ещё есть кавайные операторы >>= и <<=
            Ответить
            • ага, а еще оператор подергивания (верхнего и нижнего, ну или левого и правого)
              ++ i --; -- i ++;
              Ответить
          • Кстати, неплохо бы ввести операторы !< и !> - "не меньше" и "не больше".
            Ответить
        • попробуем достать из широких штанин логику:
          <>
          более-менее
          англ. море or лес
          Q.E.D.?
          Ответить
    • ндя. к сожалению такой народ встречается постоянно: который считает что вызов функции это очень очень дорого и компилеры не умеют инлайнить.

      ну как если бы прогресс остановился на DOS 3.30 и Turbo Pascal 5.5
      Ответить
      • А повторное вычисление H/6, cc->h-cc->w и т.п., вероятно, ускоряет код.
        Ответить
        • сами вычисления мелочи - по сравнению с тем что H имеет тип int16_t.

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

          НО. за то съекономили два байта!!! правда где съэкомили тоже не ясно потому что тот же стек выравнен как минимум на int.
          Ответить
          • short уже не нативный тип, или что вы вкладываете в это понятие ?
            Ответить
            • Возможно, он намекает использовать ptrdiff_t для целичисленных вычислений? :)
              Ответить
            • CPU делает все на регистрах. для того что бы 16-бит знаковое число получить ему нужно делать постоянно "знаковое расширение" 16-бит числа в регистр. и само собой разумеется назад из регистра обрезание до 16-бит.

              это все добавляет 1-2 инструкции почти на каждый доступ к int16_t переменной в памяти. инструкции быстрые, но тем неменее CPU пайплайн забивают.

              PS хотя тут конечно нужно учитывать баланс расхода памяти vs размер кэша данных. но даже это в принципе как правило не проблема. (cue in "cache-oblivious algorithms").
              Ответить
              • Т.е на 32 разрядном CPU лучше (с точки быстродействия) именно int32, на 64 - int64 и т.д. ?
                Ответить
                • да. просто int лучше. или еще лучше:

                  http://en.wikipedia.org/wiki/Stdint.h#Fastest_minimum-width_integer_types

                  которые на линухе например все (кроме char) опделены в long на 64битах и int на 32битах системе. ([u]int_fast8_t остается [unsigned] char)
                  Ответить
          • int16_t там возможно имеет смысл, если поля w, h и т.д. структуры cell имеют этот тип (впрочем, промежуточные вычисления всё равно в int).
            Ответить
        • Кстати, хочу заметить, что cc->h-cc->w вызывается всего 2 раза. И оба с разными аргументами. Так что ваше утверждение весьма спорно.
          Ответить
      • > Turbo Pascal 5.5
        э?
        к сведению: TP5.5 как релиз был прорывом, в первой декаде XIX в. обязательно бампнули старшую версию, а в отделе маркетинга приписали бы пару букв Х и, возможно, Z и слупили бы с юзверей по 400 баков за апгрейд. так-то.
        Ответить
        • ну я как бы преднамеренно и взял 5.5 для примера - первая реализацая ООП в паскале для ДОС. только они еще убили оптимизатор (оптимизатор третьего ТП считался очень хорошим). и модуляция (оверлеи) были сделаны через жопу. в результате, ТП5.5 штукой был хорошей, но ничего серьезного на нем было написать не возможно.
          Ответить
    • Куча magic numbers, 6-этажные условия вкупе с сокращенными до одной буквы именами полей структур... Рябит в глазах после такого.
      Ответить
      • это главная проблема этого кода:(
        Ответить

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