чтение и запись битовых структур данных

[Igors]

2) как сделать ширину поля частью структуры данных,

Не уверен что стоит ставить такую цель. Напр

Код

C++ (Qt)
struct A {
  int m_B;
  short m_C;
  ...
  char m_Z;
};

Если заменить int, short и.т.п. на нечто "содержащее битовый размер" (а это темплейт, другого не видно) это изрядно загадит текст, во всяком случае оперировать с членами будет трудно. Не применить ли KISS-прынцып (столь любимый некоторыми из нас  ). Простецкий вариант

Код

C++ (Qt)
void A::ReadWrite( CBitStream & stream, TMode mode ) 
{
  stream.ReadWriteInt(&m_B, 4, mode);    
  stream.ReadWriteShort(&m_C, 12, mode);
  ...
  stream.ReadWriteChar(&m_Z, 7, mode);
}

Он не так уж плох и работать будет.

[Old]

kambala, поясните пожалуйста, как с таким требованием:

Причем размер не всех полей известен на момент компиляции. Только точно известно, что не бывает полей шире, чем 64 бита.

вы планировали задавать размеры полей здесь?

Код

C++ (Qt)
template<N, S>
struct Field {
  bool v // if N == 1
  int8_t v // if N <= 8 && S=signed
  uint8_t v // if N <= 8 && S=unsigned
  ...
};

Устанавливать максимальным? Тогда теряется смысл с наглядностью.

[Авварон]

Писать в одно поле юниона, а читать из другово (в моих примерах) законно в любом языке. То, о чем говориться по вашей ссылке к моему случаю не имеет отношения.

Нет, не законно=) Это опять возвращает нас к разговору о reinterpret_cast и type punning.
Единственный законный способ сделать type punning в современном с++ - это memcpy.
В с++20 добавят bit_cast который сейчас можно написать самому через memcpy

Код:

template <class To, class From>
typename std::enable_if_t<
    sizeof(To) == sizeof(From) &&
    std::is_trivially_copyable_v<From> &&
    std::is_trivially_copyable_v<To>,
    To>
// constexpr support needs compiler magic
bit_cast(const From& src) noexcept
{
    static_assert(std::is_trivially_constructible_v<To>,
        "This implementation additionally requires destination type to be trivially constructible");
 
    To dst;
    std::memcpy(&dst, &src, sizeof(To));
    return dst;
}

То есть можно скопировать буфер в структуру через memcpy а вот записать int64_t а потом прочитать из битфилда на него наложеннный - нет.
Но да, все известные мне компиляторы это позволяют делать. Но clang-tidy ругается AFAIK

[juvf]

То есть можно скопировать буфер в структуру через memcpy а вот записать int64_t а потом прочитать из битфилда на него наложеннный - нет.
Но да, все известные мне компиляторы это позволяют делать. Но clang-tidy ругается AFAIK

А в чем косяк такого метода? Я понимаю когда объединили int и long. Но когда int и uint uint32_t и float - за каким углом, в какой архитектуре и с каким компилятором может быть подвох?

Это не то, чтобы "в с/с++ это предусмотрено и так нужно делать", это безопасный лайфхак. Если размер битовой структры 64 бита, и объединённого члена 64 бита, то компилятор не то что не позволит это сделать, или что-то испортит - а куда он денется с подводной лодки?

[Авварон]

Это не то, чтобы "в с/с++ это предусмотрено и так нужно делать", это безопасный лайфхак. Если размер битовой структры 64 бита, и объединённого члена 64 бита, то компилятор не то что не позволит это сделать, или что-то испортит - а куда он денется с подводной лодки?

все ненавистное UB нужно для оптимизаций.
Можно тот пример с reinterpret_cast переписать на union:

Код:

union U {
    int i{0};
    float f{0};
};

int foo()
{
        U u;
	u.i = -1;
	u.f = 0.0f;

	return u.i; // 0 или -1?
}

[kambala]

Не применить ли KISS-прынцып (столь любимый некоторыми из нас  ). Простецкий вариант

сейчас у меня примерно так и сделано, но не считаю, что это хорошее решение, надо попробовать поискать получше

kambala, поясните пожалуйста, как с таким требованием:

вы планировали задавать размеры полей здесь?

Устанавливать максимальным? Тогда теряется смысл с наглядностью.

тот пример — для известных размеров. для неизвестных, думаю, надо немножко другой контейнер, который позволит задавать ширину поля в конструкторе. подлежащий тип будет максимальным, да. наглядности с неизвестными не достичь, конечно

[juvf]

0 или -1?

0

type punning

понятно... да это вариант с type punning

[Igors]

тот пример — для известных размеров. для неизвестных, думаю, надо немножко другой контейнер, который позволит задавать ширину поля в конструкторе. подлежащий тип будет максимальным,

"Неизвестный" = содержит массив(ы) переменной длины, счетчик должен читаться/писаться в поток. Или есть др варианты?

[kambala]

0 или -1?

ответом будет:

Код:

untitled 2:4:11: error: initializing multiple members of union
    float f{0};
          ^
untitled 2:3:9: note: previous initialization is here
    int i{0};
        ^
1 error generated.

предлагаю вам ваше обсуждение об играх с юнионом перенести в другой тред

"Неизвестный" = содержит массив(ы) переменной длины, счетчик должен читаться/писаться в поток. Или есть др варианты?

не понял, счетчик чего?

неизвестный на момент компиляции, в рантайме читается из конфигурационных файлов (они всегда доступны).

[kambala]

P.S. вопрос знатокам как задать массив (обычный или std::array) из std::byte по-человечески? у меня получается только с явным вызовом конструктора для каждого элемента как в коде выше. ([unsigned] char предлагать не надо )

Код

C++ (Qt)
std::array c = {std::byte{0}, std::byte{0x78}, std::byte{0x2}};

нашел ответ: это так бай дизайн. лучше тогда брать uint8_t.

[Igors]

не понял, счетчик чего?

Счетчик эл-тов массива/контейнера - члена класса

неизвестный на момент компиляции, в рантайме читается из конфигурационных файлов (они всегда доступны).

А существующие файлы записанные с "конфигурацией X"? Выходит в поток все равно надо писать кол-во бит.

сейчас у меня примерно так и сделано, но не считаю, что это хорошее решение, надо попробовать поискать получше

Может смущает просто отсутствие новомодных цацок? Ну допустим даже удалось как-то объявить - от (полного) написания почленного I/O это все равно не избавит. И как битовые размеры (автоматом) сплавить для I/O - тоже хз.

[kambala]

Счетчик эл-тов массива/контейнера - члена класса

теперь понял. формат данных уже содержит такое поле.

А существующие файлы записанные с "конфигурацией X"? Выходит в поток все равно надо писать кол-во бит.

да, именно с такой конфигурацией. задачи конвертации между конфигурациями не стоит (но в принципе сделать можно).

Может смущает просто отсутствие новомодных цацок? Ну допустим даже удалось как-то объявить - от (полного) написания почленного I/O это все равно не избавит. И как битовые размеры (автоматом) сплавить для I/O - тоже хз.

отсутствие не смущает, но не вижу ничего плохого в том, чтобы исследовать что в них есть и как ими можно воспользоваться для улучшения кода, уменьшения писанины и увеличения наглядности/читабельности

надеюсь схитрить как-то через массив, задающий порядок полей, что-то типа:

Код:

for field in mystruct.orderedFields
  stream.write(field.size, field.value);

вроде бы на момент компиляции нельзя собрать массив полей структуры/класса? (без кодогенерации)

[Igors]

отсутствие не смущает, но не вижу ничего плохого в том, чтобы исследовать что в них есть и как ими можно воспользоваться для улучшения кода, уменьшения писанины и увеличения наглядности/читабельности

Да, я иногда тоже так рыпаюсь, пусть без особого успеха - но интересно

надеюсь схитрить как-то через массив, задающий порядок полей, что-то типа:

Код:

for field in mystruct.orderedFields
  stream.write(field.size, field.value);

вроде бы на момент компиляции нельзя собрать массив полей структуры/класса? (без кодогенерации)

Категорически утверждать "нельзя" не буду, но если и можно, то там такое мракобесие , что ну его нафиг, ото тупенько почленно расписать - сохранить и голову и время

[kambala]

Категорически утверждать "нельзя" не буду, но если и можно, то там такое мракобесие , что ну его нафиг, ото тупенько почленно расписать - сохранить и голову и время

спасибо, попробую. необязательно разбирать шаблоны сверхразума внутри библиотеки, если она решает требуемую задачу

[Old]

А давайте попробуем придумать, как удобно можно описывать и использовать такие битовые структуры.
Вот один из возможных вариантов, так сказать для затравки (здесь пока все размеры полей задаются при компиляции):

Код

C++ (Qt)
  struct record
  {
    bit_field<1> flag;
    bit_field<4> mode;
    bit_field<9> address;
 
    bit_array pack() const
    {
      return ::pack( flag, mode, address );
    }
 
    static record  unpack( const bit_array &src )
    {
      record result;
      ::unpack( src, result.flag, result.mode, result.address );
      return result;
    }
  };