Няшная / Говнокод #12143 Ссылка на оригинал

0

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
//void wyslij(int pin, char mode[] = "open") { //было
void wyslij(int pin, int mode) { //стало
  if (pin != -1)
  {
    if (mode == "open")
    {

//...

  else if ( (mode == "touch") && ( (error != 1) || (olej_error == 1) ) )

Кусок дипломной работы польского студента, код для ардуино. Выцарапано отсюда: http://vimeo.com/47656204, примерно с 1:15.

Запостил: Xom94ok Xom94ok, (Updated )

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

  • У меня все работает, что я не так делаю? http://ideone.com/bVvWJo.

    [кэп]Работать будет пока компилятор объединяет одинаковые константы в одну. Ну и пока кто-то не додумается передать туда не константу.[/кэп]
    Ответить
    • Зато как быстро работает! И не нужно вводить неинтуитивные числовые константы.
      Указатели-то побыстрее, чем строки, сравниваются.
      Ответить
      • Можно еще так - 'open', 'touc'. Но оно тоже компиляторозависимо (по стандарту компилятор может хранить такие литералы так, как ему захочется).
        Ответить
    • Самое смешное будет, когда будет передана неконстантная строка.
      Ответить
      • а твое устройство тоже не позволяет выделить и посмотреть белый текст в сообщении @Bormann?
        Ответить
        • Ну, я предполагаю, что неконстантная строка была получена откуда-то из другого источника.

          http://ideone.com/OjmQni

          Скажем, мы эти строчки считали из файла =)
          Ответить
            • А если у нас межмудольное воздействие? Линкер, думаете, будет все константы грести в кучу?
              Ответить
              • строковые константы, по идее, имеют internal linkage, но нормальный оптимизирующий линкер их таки сгребет в одну кучу
                Ответить
                • Если не подставит на месте. Оптимизирующий компилер может маленькую строку вообще в регистры засунуть, не?
                  Ответить
                  • не слышал о таком
                    все библиотечные функции, работающие со строками, работают с указателем - им нужен указатель в регистре
                    код в топике тоже оперирует указателем
                    Ответить
                    • То что строки упихаются в регистр - это конечно неправда, как с ней потом работать? Но вот кстати, gcc вполне справляется с strcmp("test", "test"), выкидывая его нахрен, и заменяя ноликом, а strlen("test") четверкой...
                      Ответить
              • Об этом я тоже писал: Работать будет пока компилятор объединяет одинаковые константы в одну.. Ну ок, если придираться к словам - то не только компилятор, но еще и линкер.
                Ответить
  • Так вот почему польские игры такие плохие.
    Ответить
  • > int mode
    > mode == "open"
    > числовая переменная сравнивается со строкой
    > Cи

    WTF_am_I_reading.jpg
    Ответить
        • Ага. Стандарт не оговаривает в каком виде хранятся multi-character literals. В данном случае авторы компилятора решили хранить последние 4 байта литерала (в нашем случае "уй" и "да" в кодировке utf-8).
          Ответить
              • То есть если я напишу в линухе: 'ху', то получу UTF8, если "ху", то однобайтовую кодировку, а если L"ху", то UTF32?

                А если я напишу в винде: 'ху', то получу однобайтовую кодировку, если "ху", то однобайтовую кодировку, а если L"ху", то UTF16?
                Ответить
                • исходный кот записан в какой-то конкретной кодировке
                  компилятор всё, что встретит русского в '' или "" будет считать, как тупо последовательность байт, которую записал программист
                  и ему будет всё равно, это был UTF-8 или бНОПНЯ, или cp-866
                  в частности, русский текст исходного кода на никсовом ideone был UTF-8, и потому в программе он ведет себя как UTF-8

                  а если ты запишешь L"", это будет const wchar_t array[N];
                  Ответить
                  • Начинает проясняться.

                    ""- в какой кодировке написал, то и будет, понятно.
                    А если написать L"", то gcc придется провести перекодировку в wchar_t. Студия соответственно перекодирует в UTF16, а gcc в UTF32. Так вот как студия и gcc определят исходную кодировку, ведь чтобы перекодировать - её нужно знать. Ключами компиляции как-то указывается?
                    И ещё получается, если исходник в кодировке UTF16 под виндой или UTF32 под линухом, то мы в "" получаем wchar_t, но зариентерпреткастенный в обычный char[N]?
                    Ответить
                    • подозреваю, что при L"unknown multibyte", если совсем неизвестно, используется пользовательская локаль, либо определенный utf, если компилятор понимал, что файл-то юникодный (типа есть BOM в начале)
                      кстати, поддерживает ли gcc 4.x BOM - не знаю
                      вот 3.х, сука, точно не поддерживает - периодически студия сохраняет русско-содержащие файлы в utf-8, и потом у gcc возникают непреодолимые трудности - как раз тот случай, если видишь эту ошибку в первый раз, то не понимаешь, что случилось
                      Ответить

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

Я, guest, находясь в здравом уме и твердой памяти, торжественно заявляю:

    А не использовать ли нам bbcode?


    8