Как уменьшить размер std::bitset?

Примерно нет.

Точнее говоря, это определяется реализаций, и «в принципе» может быть предоставлена специализация для использования uint8_t/uint16_t/uint32_t вместо size_t для мелких размеров.

Но несложно сделать penni_wise_bitset<>.

Для этого есть перечисления...

emun flag: uint8
{
Flag1 = 0b00000001
Flag2 = 0b00000010
Flag3 = 0b00000100
}

flag f = Flag1
If ( f & Flag1 ) ...

Или
struct flag{
uint8 f1 :1;
uint8 f2 :1;
uint8 f3 :1;
}

ага, потом меняем BE -> LE и всё превращается в тыкву.

С какого перепуга?

А ты не меняй... Или предусмотри.

С перечислениями ничего не превращается. На упакованную в 1 байт структуру endianess точно не влияет, но я бы пр почитал стандарт на тему как определена упаковка полей в биты.

С такого, что есть сети или файлы куда эти данные потом могут попасть. Наслаждайся: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include...

И что? Мало чего есть, если на обоих сторонах твой софт то все ок. Задача не стояла в универсальности. А в экономии.

Выше правильно пишут про Union, а про побитовый сдвиг забыли.

Пиши 3 бита в один байт, используй << и >>, напиши свой класс-оболочку. Все будет ок, можешь даже BE и LE предусмотреть.

Зачем вообще битсет — это детский сад для неосиляторов логики и сдвига.

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

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

int val;
udp.sendDatagram(QByteArray(&val, sizeof(val),...);
Приём
QByteArray data = ...
int &val = *reinterpret_cast<int*>(data.data());

Хочеш сказать, что это как-то повлияет на значение переменной val?

Ну да. Если значение не палиндром.

И как же оно изменится? (на самом деле никак.)

Я думаю, тебе хотят сказать вот это: https://stackoverflow.com/questions/6043483/why-bit-endianness-is-an-issue-in-bitfields/6044223#6044223

1 2 3 4 –> 4 3 2 1

Зачем вообще битсет — это детский сад для неосиляторов логики и сдвига.

Слишком много «осиливать» выливается в нечитабельный код и трудноловимые баги.

Пиши 3 бита в один байт, используй « и », напиши свой класс-оболочку. Все будет ок, можешь даже BE и LE предусмотреть.

Ну, не хотелось велосипедить, чесно говоря. Надеялся, что кто-то уже написал.

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

Серьезно? Плохо там у тебя в твоей параллельной вселенной...

Зависит от платформы. На TMCC2000 и на пикушки видел готовые решения от вендоров.

struct flag{
uint8 f1 :1;
uint8 f2 :1;
uint8 f3 :1;
};

Это конечно хорошо, но в моем случае больше интересует operator[]. А именно чтоб не марать руки о писание bit_reference: https://en.cppreference.com/w/cpp/utility/bitset/reference

bool array = 0b0001000;

bool operator[](int I)
{
return 0x01 & (array >> I)
}

Естественно засунь это в класс...

Можно даже через темплейт сделать для универсальности...

Серьезно? Плохо там у тебя в твоей параллельной вселенной…

Ты совсем кукухой поехал что ли?

При отправке ты высылаешь 0x12:0x34:0x56:0x78, что на little endian соответствует uint32_t 2018915346.

При приёме на big endian ты получаешь те же 0x12:0x34:0x56:0x78 в том же порядке. Но на big endian это соответствует uint32_t 305419896. Потому что старший бит здесь 0x12, а не 0x78, как на little.

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