caxapa.ru :: В моем случает так не получается, т.к. поля уже определены и они с переходом через границу байта, т.е. uint8_t x:5 не могу, нужно uint32_t x:5, но тогда размер битовой структуры получается 4 байта и все это не работает. Чтобы эту проблему решить, и используется копирование

VLLV (31.05.2020 19:23, просмотров: 280) ответил Nikolay_Po на Зачем копирование в первом варианте? Доступ к чему по индексу должен быть? К байтам? Или к битам (ХЗ как)?

В моем случает так не получается, т.к. поля уже определены и они с переходом через границу байта, т.е. uint8_t x:5 не могу, нужно uint32_t x:5, но тогда размер битовой структуры получается 4 байта и все это не работает. Чтобы эту проблему решить, и используется копирование - там лишний байт не мешает.

Ответить

- так общий размер структуры кратен размеру байта или нет? - Nikolay801_(01.06.2020 11:15)
  - Равен! Но он равен 4. Смею утверждать, что добиться нужного расположения полей и утоптать структуру в 3 байта невозможно. Кто хочет, может потренироваться. VLLV(65 знак., 01.06.2020 12:39)
    - Бойся своих желаний: PS: на x64 из-за невыравненности падает только на printf, но это проблема самой libc: - fk0(01.06.2020 13:37, ссылка, ссылка)
    - Если уж хочется экономии памяти, почему бы не утоптать в 20 бит. И по адресу/смещению выгрызать нужное поле. И более универсально будет, если через геттер/сеттер, как fk0 предложил. - Andreas(01.06.2020 13:06)
    - То есть полезная нагрузка 20 бит, но хранится в 3 байтах, по этому еще есть довесок в 4 бита? - Nikolay801_(01.06.2020 12:59)
      - Я бы эти 4 бита тоже к полезным отнес, проблема в 8 битах четвертого байта, вот они точно довесок. - VLLV(01.06.2020 13:04)
        
        Если в правильных местах расставить packed, довеска быть не должно. Логично? >>> SciFi(62 знак., 01.06.2020 13:12)
        
        Логично, но уже не очень просто (протокольные данные). Если делать промежуточный вариант структуры после парсинга протокола, то структуры обычной, а не битовой. - VLLV(01.06.2020 13:24)
        
        Немного усложняем: SciFi(122 знак., 01.06.2020 13:33)
        
        Вот это интересно, спасибо. - VLLV(01.06.2020 13:39)
    - Не использовать битовые поля, написать сеттеры-геттеры для работы с полями. В ПЯТЫЙ РАЗ ПОВТОРЯЮ. НЕ ИСПОЛЬЗОВАТЬ БИТОВЫЕ ПОЛЯ. - fk0(01.06.2020 12:47)
      - Знаешь что, Доцент, ты, конечно, вор авторитетный, но зачем ты при Мишке?(с) abivan(431 знак., 01.06.2020 15:03)
        
        Нарваться на несовместимость битовых полей можно на одном компиляторе при переходе с версии на версию: см 4-й пункт сверху --> - fk0(01.06.2020 22:04, ссылка)
        
        я всегда явно дополняю падинг биты. А у компилятора баги и не только в битовых полях могут быть. abivan(232 знак., 01.06.2020 22:41)
        
        Проблема в том, что конкретные особенности реализации битовых полей -- никем не гарантируются. Компилятор имеет полное право битовые поля хранить как текст на русском матерном языке, если авторы захотят. - fk0(01.06.2020 23:23)
        
        А ещё кирпич на голову может упасть. Поэтому из дома не выходи. - SciFi(02.06.2020 08:45)
        
        A потом тут ноют (с чего топик и начался), памажите люди добры, не работает. - fk0(02.06.2020 11:27)
      - Спасибо, вот наконец то прямой ответ ;) А почему? - VLLV(01.06.2020 12:56)
        
        потому что тогда код писанный для мсп430 не сможет работать на SPARC, на котором его никогда не будут использовать. Nikolay801_(30 знак., 01.06.2020 13:40)
  - sizeof(struct foobar) == 1.83? O_o - SciFi(01.06.2020 11:37)
    - 1.875 Nikolay801_(97 знак., 01.06.2020 11:49)
      - Сомневаюсь, что ваше понимание того, что делает __packed, соответствует реальности. По поводу sizeof придираться не буду, считая это игрой слов :-) - SciFi(01.06.2020 11:58)

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