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

    +137

    1. 1
    2. 2
    3. 3
    4. 4
    if (MACaddress == 0)
		MACaddress = pAdapterInfo->Address [5] + pAdapterInfo->Address [4] * 256 + 
					pAdapterInfo->Address [3] * 256 * 256 + 
					pAdapterInfo->Address [2] * 256 * 256 * 256;

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

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

    • ava daemon_master 12.12.2010 15:59 # 0

      нахуя?
      Ответить

    • ava Dummy00001 12.12.2010 16:40 # +2

      так а где говно?

      ну хоть бы уже куда комментарий "лопата" добавляли.
      Ответить

      • ava TarasB 12.12.2010 17:17 # +1

        Говно в том, что число собирается по байтам таким кривым образом.
        Ответить

        • ava Dummy00001 12.12.2010 17:29 # +2

          почему кривым?

          это стандартный портабельный способ собирания целого числа из байтов, работающий в независимости от strict alignment и от endianess. "стандртный" способ. я такой код (с мелкими вариациями) вижу почти каждый день.

          и меньше писать по сравненю со сдвигами, потому что для сдвигов нужно еще и конвертировать каждый байт из памяти в unsigned int - иначе обрезание происходить будет.
          Ответить

          • ava Oleg_quadro 12.12.2010 19:31 # +3

            а чего маленький циклик не забабахать? от 2 до 5
            Ответить

            • ava inkanus-gray 12.12.2010 20:17 # 0

              Разворачивание циклов — это оптимизация по скорости. Зачем нам лишние счётчики и проверки условий?
              Ответить

            • ava Dummy00001 12.12.2010 20:22 # +2

              так а на кой? этот код пишется раз, а потом он просто работает. это может народу с непривычки в глаза бросается, но тем кто сетевые сервера и протоколы делает, этот код выглядит как "2*2=4"

              да и цикл то как бы проще не будет. доп переменная понадобится. или две (для множителя/сдвига). народ пытается что бы простое обращение к памяти было как можно проще, и уж точно без flow control. разворачивание циклов оптимизатором тоже не гарантируется.
              Ответить

    • ava eth0 12.12.2010 17:09 # +2

      Будь адрес десятибайтовым, задолбались бы умножать на 256.
      Ответить

      • ava inkanus-gray 12.12.2010 17:22 # +8

        Можно оптимизировать по схеме Горнера: 
        MACaddress = pAdapterInfo->Address [5] + 256 * (pAdapterInfo->Address [4] + 
256 * (pAdapterInfo->Address [3] + 
256 * pAdapterInfo->Address [2]));
        Задолбается тогда автор скобки считать!
        Ответить

    • ava xaionaro 13.12.2010 13:26 # 0

      Да вроде нормальный код. Разве что лично я предпочитаю использвать "(1<<8)" вместо "256" и "(1<<16)" вместо "256*256" соответственно (конкретно в данной ситуации я бы операцию умножения вообще не использовал, т.к. операции сдвига вполне хватает)
      Ответить

      • ava TarasB 13.12.2010 13:31 # +4

        Кстати как раз в данном случае битовые сдвиги действительно нагляднее, чем умножение.
        Ответить

    • ava Анонимус 13.12.2010 13:47 # 0

      ололо
      шифтов мы не проходили
      Ответить

      • ava xaionaro 13.12.2010 13:56 # 0

        Не использование сдвигов - не повод ни смеяться, ни выкладывать код сюда ;)
        Ответить

        • ava Анонимус 13.12.2010 14:05 # 0

          а умножение на 256 три раза -- повод?
          Ответить

          • ava xaionaro 13.12.2010 14:53 # 0

            Нет. И я уже, кажется, косвенным способом об этом сказал в своём первом комментарии по этой теме.
            Ответить

    • ava TheCalligrapher 14.12.2010 20:30 # 0

      Код абсолютно нормальный. Более того, код исключительно грамотный. Во-первых, использован правильный способ собирания числа из байтов (арифметика, а не пихание байтов в память) . Во-вторых, показано структура "магических констант", т.е. явно расписано `256 * 256`.

      Можно поспорить о том, не лучше ль было бы тут использовать сдвиги (возможно, лучше)... Но говнокодом тут и близко и не пахнет. Пахнет профессионализмом очень высокого уровня или по крайней мере зачатками такого профессионализма.
      Ответить

      • ava xynta 15.12.2010 00:49 # +1

        вы меня убедили. Просто такой способ перевода big/little endian меня, как бывшего ассемблерщика привел в недоумение
        Ответить

    • ava sanchousf 17.12.2010 18:21 # 0

      Намисал бы уже 0x100*0x100 или 0x10000, помоему так нагляднее
      Ответить

      • ava xaionaro 18.12.2010 00:57 # 0

        Ну а мне нагляднее всего сдвиги [и компилятору стараться не надо :)]. Кому-то нагляднее куча "256". Это всё лишь строго стилистика конкретного программиста. ;)
        Ответить

    • ava Говногость 17.12.2010 23:16 # 0

      Компилятор это в сдвиги сам преобразует, так что отличный код.
      Ответить

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