caxapa.ru :: Эфемерное "good practice" в программировании на С: Данность : есть массив[x] массивов[3]. Эти три байта на самом деле битовая структура, но для экономии места обрезали один байт. Как сделать доступ к полям структуры по индексу из нескольких мест? Два варианта:

"good practice" в программировании на С это не "эфемерное", это оксюморон. Почувствуйте разницу. - Kpoк(31.05.2020 23:20)

Сделал изначально какую-то херню, теперь ещё голову ломает. Я уже говорил: 1) битовые структуры -- НЕ НУЖНЫ (адресуй нужный байтик и маскируй в нём нужный битик); 2) упакованные структуры тем более НЕ НУЖНЫ. 3) для эффективной адресации нужно завести не массив структур, а коллекцию (структуру) массивов для разных элементов твоих структур (т.е. массив первых элементов структур, массив вторых...), тогда всё эффективно адресуается без битовых полей, без упаковки и прочей fk0(7 знак., 31.05.2020 21:03)

Зачем копирование в первом варианте? Доступ к чему по индексу должен быть? К байтам? Или к битам (ХЗ как)? Nikolay_Po(450 знак., 31.05.2020 17:51)

В моем случает так не получается, т.к. поля уже определены и они с переходом через границу байта, т.е. uint8_t x:5 не могу, нужно uint32_t x:5, но тогда размер битовой структуры получается 4 байта и все это не работает. Чтобы эту проблему решить, и используется копирование - там лишний байт не мешает. - VLLV(31.05.2020 19:23)
- так общий размер структуры кратен размеру байта или нет? - 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)

я бы сделал (и делаю) прямой как шпала тайпкаст кaлян(213 знак., 31.05.2020 15:29,

)

перестанет работать на типах длиннее 1 байта - 3m(01.06.2020 13:45)
А разве сами данные не надо массивом из 3072 uint8_t объявить? А то получается, что массив указателей на данные есть, а вот самих данных - нет. Ну или астериск из объявления массива arr[1024] убрать. - Nikolay_Po(31.05.2020 17:56)
- Да * там лишняя, Спасибо. - Nikolay801_(01.06.2020 11:12)

Не адресуй указателями packed struct'ы/bitfields, в этом проблема. (Обращение по индексу это форма обращения по указателю). - RxTx(31.05.2020 12:29, ссылка)

1) Я бы делал memcpy. 2) Раз уж речь о "good practice", порядок заполнения битовых полей implementation-defined, то есть строго говоря неясно, какой байт лишний -- нулевой или третий. - SciFi(31.05.2020 12:09)

2) ни разу не встречал. - VLLV(31.05.2020 19:24)

3) Обернуть это в ~~методы~~ функции set_field/get_field, внутри которых что юнион, что битовые операции - одинаково читабельно. - Cкpипaч(31.05.2020 11:53)

ну я в таком случае смержил бы оба пункта, 1) определил бы фиктивный union на uint32: битовые поля, сташий байт пустой. а потом с его помощью опредял бы указатель на 3 байтовый элемент массива массивов. далее как сказано компилятор сам вытащит значения полей. ничего копировать не надо. лошадь сильная - пущайй сама и двигает биты и OR над ними делает. - klen(31.05.2020 01:04)

Увы, это как раз и не работает (hardfault из-за невыравненного доступа) - VLLV(31.05.2020 08:53)
- а ежели так, то по любому не получится в исходном массиве разбираться по отдельным кускам, ибо 3 не четное и через одно будет залет на хард фаулт, только через копию. Nikolay801_(337 знак., 01.06.2020 11:35)
  - Ну я же могу сделать и так VLLV(238 знак., 01.06.2020 12:52)
    - можете, но и компилятор тоже может, а он железный пускай пашет. - Nikolay801_(01.06.2020 13:30)
      - В том то и дело, что пашет он глубже в случае структур. Собственнө вопрос рисков : собственные ошибки или ошибки [использования] компилятора. - VLLV(01.06.2020 22:18)
- А что за ядро? ARMv6 и выше, по идее, умеют в невыравненный доступ. - s_h_e(31.05.2020 09:57)
  - мсп430, там живет такой прикол - кaлян(31.05.2020 15:28, )

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