caxapa.ru :: Оказалось всё не так просто. Для битовых полей есть исключение.

ЫЫукпу (11.02.2019 00:21, просмотров: 172) ответил Codavr на Неожиданно захотелось производить операции с элементами битовых полей. По каким правилам с СИ делаются с ними операции, как с int-ами, или какие извращения имеются?

Оказалось всё не так просто. Для битовых полей есть исключение. "...except that for bit-ﬁelds, it is implementation-deﬁned whether the speciﬁer int designates the same type as signed int or the same type as unsigned int." То есть если знаковость указана явно, то и трактуется как указано. А если просто int, то implementation-deﬁned. И ещё поле с типом _Bool ведет себя как положено булевскому, принимает значения только 0 или 1 независимо от ширины поля.

Ответить

- Это из стандарта вынуто или народ уже в процессе юзания компилеров находит такие веселухи? - Codavr(11.02.2019 09:17)
  - Это из INCITS/ISO/IEC 9899-2011[2012], раздел 6.7.2 Type speciﬁers, пункт 5. ЫЫукпу(546 знак., 11.02.2019 11:40 - 12:14)
    - Спасибо. - Codavr(11.02.2019 11:44)
- А еще в MS Visual Studio сдвиг unsigned long long вправо на 64 бита дает в результате всякую х.йню. - Хаос(11.02.2019 08:18, )
  - Чем мотивируют? - Codavr(11.02.2019 09:45)
    - Ничем не мотивируют. Вот цитата из хелпа к MS VS: Хаос(265 знак., 11.02.2019 11:14, )
      - Могли бы и на стандарт сослаться, в 6.5.7 Bitwise shift operators (С) и 5.8 Shift operators (С++) именно так и сказано. А ещё сдвиг вправо implementation-deﬁned для знаковых если значение отрицательно. - ЫЫукпу(11.02.2019 13:22)
        
        Я сейчас пишу в основном на Verilog'e, поэтому стандарта С++ под рукой просто нет. А хелп, вот он, рядом. :) - Хаос(11.02.2019 14:31, )
        
        Во во, еще немного и стандарт можно будет заменить одной фразой implementation-deﬁned. - Codavr(11.02.2019 14:18)
      - Звыняйте хлопцы, так получилось :( - Codavr(11.02.2019 11:57)
        
        Есть большое подозрение, что это особенность процессоров Intel, а не компилятора MS VS. Операция сдвига слишком проста и там нет места для творчества криворукого программиста. - Хаос(11.02.2019 12:18, )
        
        Скорее всего. Если бы дело было в софте, то поправили бы моментально. - Codavr(11.02.2019 12:29)
        
        Компилятор IAR не сдвигает влево больше чем на 32 бита и никто его не рвется править. - VLLV(11.02.2019 12:32)
        
        Вопрос не в "больше чем 32 бита", а вопрос в "равно 32-м битам". Хаос(404 знак., 11.02.2019 13:04, )
        
        Ограничение 32/64 (длина машинного слова ARM/Intel) в общем то логично, или компилятор, или пользователь (неважно кто) должен проверять аргумент, от того, кто это делает, замедление алгоритма не зависит. Или? - VLLV(11.02.2019 13:18)
        
        Как бы привычно и логично, что при сдвиге беззнакового вправо в старший задвигается нолик. Логично предполагать что скока ни сдвигай он туда и будет писаться. Если бы не предупредили, то у меня и мысли бы не возникло проверять так ли это. - Codavr(11.02.2019 14:09 - 14:14)
        
        У меня тоже "и мысли не возникало проверять так ли это", пока не стал делить полиномы 4095-ой степени над полем Галуа друг на друга. Вот тут то все и началось.. Пол дня искал причину, почему декодер БЧХ не хочет декодировать пакеты. :) - Хаос(11.02.2019 14:29, )
        
        Могу себе представить как ты матерился, когда разобрался :))) - Codavr(11.02.2019 14:36)
        
        Аццки!!! - Хаос(11.02.2019 14:38, )
        
        Ну, например, в сигнальных процессорах ADI это никому не нужно делать. Результат сдвига на ширину машинного слова всегда нулевой, так зачем тогда тратить время на эту проверку? - Хаос(11.02.2019 13:23, )

Средства и методы разработки