Size: a a a

2021 February 15

A

Arelav in pro.cxx
источник

m

magras in pro.cxx
Dmitriy
tag 1 | (tag2 << 48)
А вот порядок в котором будут лежать поля bit field'а на сколько я помню implementation defined.
источник

АГ

Алексей Григоренко... in pro.cxx
Добрый день, коллеги.
Мы с командой продуктовой аналитики проводим исследование касательно использования и закупки в работе зарубежного ПО. Будем признательны, если вы поможете нам и пройдете небольшой опрос (всего 6 вопросов).
Сам опрос
источник

KZ

Konstantin Zhukov in pro.cxx
magras
А вот порядок в котором будут лежать поля bit field'а на сколько я помню implementation defined.
Именно. На BigEndian архитектуре поля будут идти наоборот: от старшего бита к младшему.
источник

m

magras in pro.cxx
Konstantin Zhukov
Именно. На BigEndian архитектуре поля будут идти наоборот: от старшего бита к младшему.
На сколько я помню, по стандарту порядок не привязан к endianess, поэтому даже на это полагаться опасно.
источник

m

magras in pro.cxx
Да и endianess не совсем про это. Оно задает порядок байт. А здесь речь идет о битах.
источник

s

std::slavik in pro.cxx
Dmitriy
Разрешает ли Стандарт делать такое?
struct Tag {
 uint64_t tag1 : 48;
 uint64_t tag2 : 16;
};
Где-то в коде ниже:
Tag t;
...
auto val = *reinterpret_cast<uint64_t*>(&tag);
не
источник

s

std::slavik in pro.cxx
Konstantin Zhukov
Именно. На BigEndian архитектуре поля будут идти наоборот: от старшего бита к младшему.
это не связано - компилятор может из своих соображений местами менять
источник

s

std::slavik in pro.cxx
источник

KZ

Konstantin Zhukov in pro.cxx
std::slavik
это не связано - компилятор может из своих соображений местами менять
Может, но на практике это связано. https://www.keil.com/support/man/docs/armcc/armcc_chr1360774870320.htm
источник

KZ

Konstantin Zhukov in pro.cxx
Недавно на работе на эту проблему наткнулся.
источник

s

std::slavik in pro.cxx
As an optimization, the compiler might overwrite padding bits in a container with unspecified values when a bitfield is written. This does not affect normal usage of bitfields
источник

s

std::slavik in pro.cxx
короче в рамках одной платформы можно, но не нужно, лучше честно заполнять каждое поле, сейчас оно работает, через месяц уменьшили поле на пару бит какоенить и компилятор решил ченить подравнять и все посыпалось
источник

ZZ

Zorro Zorroff in pro.cxx
Добрый день, коллеги. Компилятор компилит функцию, в ней куча инлайнов. Очень неэффективно расходуется стек: совершенно разные пути исполнения, буквально перед разными return разные инлайн функции, по уму они могут реюзать адреса на стеке, а получается что нет. Какое щас состояние дел у clang в этом вопросе? Особые ключи?
источник

АР

Андрей Руссков... in pro.cxx
а как вы замерили что стек используется неэффективно?
источник

ПК

Побитый Кирпич... in pro.cxx
Zorro Zorroff
Добрый день, коллеги. Компилятор компилит функцию, в ней куча инлайнов. Очень неэффективно расходуется стек: совершенно разные пути исполнения, буквально перед разными return разные инлайн функции, по уму они могут реюзать адреса на стеке, а получается что нет. Какое щас состояние дел у clang в этом вопросе? Особые ключи?
Кидай пример на годболт
источник

AT

Alexey Tkachenko in pro.cxx
и почему вы решили, что он будет использоваться эффективнее, если убрать инлайнинг
источник

ZZ

Zorro Zorroff in pro.cxx
предположил, потому что локальные переменные инлайн функций тоже требуют место на стеке. Годболт это отличная идея, щя
источник

ZZ

Zorro Zorroff in pro.cxx
а на годболт можно запустить код?
источник

ПК

Побитый Кирпич... in pro.cxx
Zorro Zorroff
а на годболт можно запустить код?
Да
источник