На главную
ПРАВИЛА FAQ Помощь Участники Календарь Избранное DigiMania RSS
msm.ru
Соблюдайте Правила
Модераторы: Модераторы, Комодераторы
Страницы: (57) « Первая ... 26 27 [28] 29 30 ...  56 57  ( Перейти к последнему сообщению )  
    > "Я хочу пойти в айти". из юристов в программисты
      Цитата Qraizer @
      послушать претендента и сделать предварительные выводы о его аналитических способностях.
      Это больше похоже на оценку способности претендента фантазировать. Я, например, заметил эту странность и указал бы на нее на собеседовании. Но мне бы и в голову не пришло, что собеседующий ждет длинных фантазийных историй придуманных на основании нескольких простейших строчек кода.
      Сообщение отредактировано: applegame -
      error: 'long long long' is too long for GCC
        я бы сказал, что это скорее тест на выявление "узкоспециализированности" человека. ну то есть, если человек берётся на написание нового кода - то логичной реакций на такой код будет - увольте тех, кто так пишет или зачем вообще такие конструкции сочинять? а если человека планируется ставить на рефакторинг, то подобный анализ вполне уместен.
          Цитата bum @
          Да стебётся он над вами, а вы и ведётесь.

          Не порти людям эту игру.
            Цитата applegame @
            Но мне бы и в голову не пришло, что собеседующий ждет длинных фантазийных историй придуманных на основании нескольких простейших строчек кода.
            Та не ждёт он ничего конкретного. Заметил, уже хорошо, значит есть качества, приветствуемые верификатору. Практически все претенденты вообще ничего особенного в этой функции не видят, но это не значит, что они не подойдут.
            Одни с годами умнеют, другие становятся старше.
              Цитата Qraizer @
              Практически все претенденты вообще ничего особенного в этой функции не видят, но это не значит, что они не подойдут.

              А вот с двойным отрицанием - там в чем прикол, всё-таки?
              Над нами - правила форума, внутри нас - нравственный закон!
              (Девиз начинающего модератора.)
                Та откуда я знаю. Я код не писал. Обход бага в компиляторе, задержка исполнения, отладочный глитч для брякпоинта по доступу к регистру, банальная невнимательность из-за исправления несоответствия кодестайлу... Подозреваю последнее, т.к. скорее всего ==0x2000 не было, и ! применялась сразу к результату &.
                Одни с годами умнеют, другие становятся старше.
                  Под 16-битные контроллеры я ничего не писал, там вообще засады не может быть с битовыми операциями в старшем слове лонга? (я думал может тут подстава)
                    Цитата ter_nk_ @
                    (я думал может тут подстава)
                    Вообще-то именно в этом. Только засада не в микроконтроллере, а в его 16-битности. Я ж не зря в самом начале процитировал отсылку к Borland C++ 3.1 ;)
                    Одни с годами умнеют, другие становятся старше.
                      Цитата Qraizer @
                      Только засада не в микроконтроллере, а в его 16-битности.


                      Понятно, значит там просто могут значения не меняться. Надо это слово копировать в двухбайтовую переменную, менять биты, копировать со сдвигом в лонг. Хотя с точки зрения архитектуры непонятно зачем для этих целей содержать лонг.

                      Добавлено
                      На мысль о подставе там меня навел Исмаил своими рассуждениями о простоте и сложности.
                        Цитата applegame @
                        Цитата Qraizer @
                        послушать претендента и сделать предварительные выводы о его аналитических способностях.
                        Это больше похоже на оценку способности претендента фантазировать. Я, например, заметил эту странность и указал бы на нее на собеседовании. Но мне бы и в голову не пришло, что собеседующий ждет длинных фантазийных историй придуманных на основании нескольких простейших строчек кода.

                        Плюсую.
                        Вы выразили мои мысли только своими словами.
                        Что-то высасывать и делать выводы вселенского масштаба на основании анализа претендентом нескольких строчек кода...
                        Написать код, понятный машине, и дурак сможет. И только хороший программист сможет написать код, понятный людям
                          Цитата Исмаил Прокопенко @
                          Вы выразили мои мысли только своими словами.
                          Что-то высасывать и делать выводы вселенского масштаба на основании анализа претендентом нескольких строчек кода...


                          Хорошо, надо дать страницы кода полного ошибок и попросить написать подробный отчет :) все правильно, в большом объеме человек что-то по невнимательности не заметит.
                            Давайте я перепишу код, чтоб было более приближено к действительности. (Надеюсь, его авторы его тут всё-таки не узнают.) Заодно это вскроет ещё одну занятную проблему.
                            ExpandedWrap disabled
                              const unsigned long cIdeCFG  = 0x1BFB0002;
                              const unsigned long cSubField= 0x00038002;
                                             int  NoUnt, ShtUnt, RegImsk, NomController, ShtMSK, NoMSK;
                               
                              void LoadBuffer(long IdeOut);
                               
                              void init(void)
                              {
                                 int Teg;
                               
                                 Teg   = (PORTD >> 1) & 0xF;
                                 NoUnt =  Teg;
                                 ShtUnt= (NoUnt << 10);
                                 NoMSK = 2;
                                 ShtMSK= 0x0C;
                               
                                 RegImsk = (PORTA & 0xE000);
                                 NomController = !!((RegImsk & 0x2000) == 0x2000);
                                 ShtMSK = ShtMSK | NomController;
                              }
                               
                              void blah_blah_blah(void)
                              {
                                 long IdeOut;
                               
                                 IdeOut = cIdeCFG | cSubField | ShtUnt | (NoMSK<<7) | ShtMSK;
                               
                                 LoadBuffer(IdeOut);
                                 asm("nop");
                              }


                            Добавлено
                            В общем подсказка уже прозрачней некуда. Так что вот.
                            Функция собирает управляющее слово протокола, которое состоит из нескольких полей. Там в частности наличествуют поля, кодирующие кому и от кого идёт посылка и принципиальные идентификаторы типа посылки и кода конкретной команды. Поэтому там много битовых операций, т.к. многие из полей константные для конкретного исполнительного узла (вон те const unsigned long), но при этом не фиксированы на уровне его программной архитектуры, а определяются, скажем, по распайке, перемычкам и вообще конструкторской документации (приветы от PORTA и PORTD, да.)
                            В тупик поставило, во-первых, то, что две константы 0x1BFB0002 и 0x00038002 своими битами 1, 16 и 17 пересекаются. Как бы когда единое слово собирается из отдельных частей, у каждого поля свои диапазоны бит, так что пересечение битовых полей уже как-то сильно странно, и заставляет задуматься как раз над фактами, как выше на собеседовании. Конечно, кто не найдёт ничего странного в функции get(), вряд ли заострит своё внимание и тут. Привет, Исмаил Прокопенко, забирай свои $100 тыщ зимбабвийских, на завтрак с хреном хватит. Такая же шняга имеет место и с другими переменными. Кто гарантирует, что они обязательно будут в пределах своих полей? А ежели криворукий ынжинер перемкнёт припоем ноги? Или завтрашний пенсионер не разглядит в документации единичку в битовом поле? Что-то мне подсказывает, пенсии ему будет не видать до конца жизни его правнуков, вертолёты нынче дорогие.
                            В общем и целом, я ожидаю, что грамотный программист при одном только взгляде на этот код скажет, что очень нехорошо собирать битовые поля OR-ами, не ограничивая их значения AND-ами. Но это только цветочки, т.к. в новом варианте появилось – вообще-то оно и раньше было, только замаскировано, а в исходном коде было изначально – ещё и во-вторых.

                            Добавлено
                            Типы констант unsigned long, т.е. 32-битный, типы остальных локальных переменных int, т.е. 16-битный. причём и знаковость разная. Это значит, что перед выполнением | над операндами будет выполняться integral promotion, которое говорит, что... не буду цитировать Стандарт, короче: при смешивании 32-битного беззнакового и 16-битного знакового последний сначала приводятся к 32-битному знаковому, и только затем к беззнаковому. Фэйл-сценарий, к примеру: на порту D напаян номер модуля, который по документации стал 6-битным. Это сейчас он ограничивается 4-мя битами, но это видно только по коду, в документации об этом ни слова, и вообще это отдельная функция. Поэтому любой тестер, не говоря уже о верификаторе, занимающимся авионикой, костьми ляжет, но подаст граничные значения классов эквивалентности. В результате достаточно будет всего лишь циферки 32, чтобы получилось 16-битное 0x8000, которое отпромотится до 0xFFFF8000.
                            Одни с годами умнеют, другие становятся старше.
                              То что две константы имеют пересекаются ставит в тупик - это если они нигде больше не используются, но тогда бы незачем было писать две константы, а где и как они используются в других кусках неизвестно.

                              Цитата Qraizer @
                              В общем и целом, я ожидаю, что грамотный программист при одном только взгляде на этот код скажет, что очень нехорошо собирать битовые поля OR-ами, не ограничивая их значения AND-ами.


                              Как ты будешь тут их ANDом собирать?

                              Цитата Qraizer @
                              IdeOut = cIdeCFG | cSubField | ShtUnt | (NoMSK<<7) | ShtMSK;


                              Кстати мне было непонятно, зачем для битовых операций использовать знаковый int, когда беззнаковый должен быть быстрее в операциях, ну и этих граблей бы не было.
                                Знаешь, ter_nk_, мы два дня эпизодически обсуждали сие. Ведь не исключено даже, что так и задумано, чтобы где-нибудь на пультах пилотов, скажем, лампочки позажглись. Фэйл-сценарий написать просто невозможно, потому что поведение кода чётко однозначно. В конце-концов пришли к соломоновому решению: разбить классы эквивалентности спорных переменных на два диапазона, со сброшенным знаковым битом и с установленным, и написать СП на подозрительное поведение кода для второго диапазона, ведущего к нарушению протокола взаимодействия модулей.
                                Цитата ter_nk_ @
                                Как ты будешь тут их ANDом собирать?
                                Не собирать, а ограничивать битовые поля. Что-то типа:
                                ExpandedWrap disabled
                                  IdeOut = cIdeCFG | cSubField | (ShtUnt & 0x0000FC00) | ((NoMSK<<7) & 0x00000300) | (ShtMSK & 0x0000000F);
                                как это обычно и делают нормальные программеры. Здесь битовые маски я выбрал условно, бо как просто не помню битовых полей из протокола.
                                Сообщение отредактировано: Qraizer -
                                Одни с годами умнеют, другие становятся старше.
                                  Цитата Qraizer @
                                  как это обычно и делают нормальные программеры

                                  Только ты к ним не имеешь никакого отношения
                                  Написать код, понятный машине, и дурак сможет. И только хороший программист сможет написать код, понятный людям
                                  0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                                  0 пользователей:
                                  Страницы: (57) « Первая ... 26 27 [28] 29 30 ...  56 57


                                  Рейтинг@Mail.ru
                                  [ Script Execution time: 0,1718 ]   [ 17 queries used ]   [ Generated: 21.11.17, 15:55 GMT ]