t
ну ладно сам подумаю еще как сделать да решу проще
Size: a a a
2021 February 27
MK
вы почему-то считаете, что результат чтения из одинакового адреса будет одинаковым
Вообще то будет. If two union members are standard-layout types, it's well-defined to examine their common subsequence on any compiler.
CD
Вообще то будет. If two union members are standard-layout types, it's well-defined to examine their common subsequence on any compiler.
это не одно и то же
CD
я говорю о том, что результат чтения из равных указателей может зависеть от способа получения указателя
CD
именно поэтому существует std::launder
MK
я говорю о том, что результат чтения из равных указателей может зависеть от способа получения указателя
А ну да..
t
нужно было не char а unsigned char
MK
именно поэтому существует std::launder
Ну а причем тут виртуальные указатели то? мы же вроде о простых типах говорили. В памяти это просто байты безо всякой магии. Если работает memcpy, то и чтение из union должно (если компилятор вообще такое позволяет)
MK
нужно было не char а unsigned char
Но, все таки не надо так union использовать, рано или поздно это кончится плохо, лучше всего копировать байты из double в заранее подготовленный буфер.
t
да я понял
CD
Ну а причем тут виртуальные указатели то? мы же вроде о простых типах говорили. В памяти это просто байты безо всякой магии. Если работает memcpy, то и чтение из union должно (если компилятор вообще такое позволяет)
Мы объектную модель в memcpy не ломаем, это важно. Байты объекта можно читать, но, скажем, неактивные члены юниона не объекты
MK
Мы объектную модель в memcpy не ломаем, это важно. Байты объекта можно читать, но, скажем, неактивные члены юниона не объекты
Ну, да, нет никаких гарантий, что прочитается что-то осмысленное.
CD
Ну а причем тут виртуальные указатели то? мы же вроде о простых типах говорили. В памяти это просто байты безо всякой магии. Если работает memcpy, то и чтение из union должно (если компилятор вообще такое позволяет)
И да, про байты в памяти - а в регистрах? У регистров нет адресов
MK
И да, про байты в памяти - а в регистрах? У регистров нет адресов
Union всегда в памяти (в конечном итоге). Более того, в стандарте четко описано что а) размер union соответствует размеру его самого большего поля и б) все поля имеют один адрес. Правда есть еще в) чтение только из последнего записанного члена, все остальное UB и г) многие компиляторы реализуют нестандартное расширение, позволяющее читать неактивные члены.
CD
Union всегда в памяти (в конечном итоге). Более того, в стандарте четко описано что а) размер union соответствует размеру его самого большего поля и б) все поля имеют один адрес. Правда есть еще в) чтение только из последнего записанного члена, все остальное UB и г) многие компиляторы реализуют нестандартное расширение, позволяющее читать неактивные члены.
А при вызове функции юнион размером 8 байт будет лежать в стеке? Он ведь тривиально копируем
MK
А при вызове функции юнион размером 8 байт будет лежать в стеке? Он ведь тривиально копируем
Не факт, компилятор может передать его через регистр, благо он туда влезет. Весь вопрос в механике расширения из последнего пункта. Ну и для задачи «прочитать double побайтно» не обязательно вообще вызывать функцию с union-ом в качестве аргумента.
CD
Речь о том, что пункт (г) это жуткая легасятина и нетривиальные действия компилятора.
CD
Искать там даблы, которые записаны через AL
MK
Речь о том, что пункт (г) это жуткая легасятина и нетривиальные действия компилятора.
Есть такое, и я согласен, что этим не стоит пользоваться. union в общем не плохая штука, но его надо использовать как то так
struct {Type type; union {double d; char c}} где Type enum {DOUBLE_TYPE, CHAR_TYPE}MK
Код скорее всего не совсем корректный, но идею описывает.