Как работает union в С++

Здравствуйте, подскажите пожалуйста.
Как работает union в С++
Везде написано, что элементы union, занимают одну область памяти.
Область памяти размером по наибольшему элементу.

Если я присвою int какое либо значение.
И присвою значение для char.
И учитывая, что они занимают одну область памяти.
Значит char должна затереть часть битов int.
И int перестанет иметь прежнее значение.

0

Verevkin, это не разрешается программисту, а компилятор - он глупый, он верит человеку

Например, не разрешается разыменовывать нулевой или провисший указатель. Не разрешается организовывать гонку данных. Не разрешается нарушать strict aliasing.
Но компилятор всё это преспокойно пропускает.

0

Сообщение от Verevkin Что такое активность члена union?

Попросту выражаясь, тот член, в который последним выполнялась запись - активный. Остальные - неактивны.

Сообщение от Verevkin Это ж просто начальный адрес в памяти. И всё.

При чем здесь начальный адрес в памяти и каким боком это относится к С++ - мне не ясно.

Сообщение от Verevkin то компилятор обязан это не пропустить.

Во-первых, в С++ существует большое количество ошибок времени компиляции, которые являются недиагностируемыми ("no diagnostic required"). Так что ни о каком "обязан" речи никогда не шло даже в случае ошибок, которые компилятор теоретически может отловить

Во-вторых, к "не разрешается" я также отношу неопределенное поведение, как в данном случае.

0

Сообщение от TheCalligrapher Попросту выражаясь, тот член, в который последним выполнялась запись - активный. Остальные - неактивны.

Первый раз такое слышу. Пруфы, хоть, дай.

Сообщение от TheCalligrapher При чем здесь начальный адрес в памяти и каким боком это относится к С++ - мне не ясно.

Ну, переменная типа union (и её поля) - это жэж начальный адрес данных, которые она (они) хранит (хранят). А типы полей определяют их размеры, причём самое длинное поле задаёт размер всего union. В Си и паскале - так. Разве в С++ это не так? Почему? А как тогда?

Сообщение от TheCalligrapher к "не разрешается" я также отношу неопределенное поведение, как в данном случае.

Я помню, Задорнов говорил про 3 типа "нельзя": "запрещено", "строго запрещено" и "категорически запрещено!!!".
Ну, поржать можно, однако, что не так c кодом моего примера? Что в нём может пойти не так? Покажи, пожалуйста, на практике, а то я не смогу в это поверить: у меня слово "недопустимо" ассоциируется именно c "категорически запрещено".

Очень прошу, Маэстро!

Добавлено через 2 минуты

Сообщение от Алексей1153 это не разрешается программисту, а компилятор - он глупый, он верит человеку Например, не разрешается разыменовывать нулевой или провисший указатель. Не разрешается организовывать гонку данных. Не разрешается нарушать strict aliasing. Но компилятор всё это преспокойно пропускает.

Здесь - не тот случай. Не передёргивай.

0

Сообщение от Verevkin Пруфы

In a union, a non-static data member is active if its name refers to an object whose lifetime has begun and has not ended ([basic.life]). At most one of the non-static data members of an object of union type can be active at any time, that is, the value of at most one of the non-static data members can be stored in a union at any time. [Note 1: One special guarantee is made in order to simplify the use of unions: If a standard-layout union contains several standard-layout structs that share a common initial sequence ([class.mem]), and if a non-static data member of an object of this standard-layout union type is active and is one of the standard-layout structs, the common initial sequence of any of the standard-layout struct members can be inspected; see [class.mem]. — end note]

https://eel.is/c++draft/class.union#general-2

Добавлено через 5 минут

... if the object is a union member or subobject thereof, its lifetime only begins if that union member is the initialized member in the union ([dcl.init.aggr], [class.base.init]), or as described in [class.union], [class.copy.ctor], and [class.copy.assign], and except as described in [allocator.members]. The lifetime of an object o of type T ends when: (1.3) if T is a non-class type, the object is destroyed, or (1.4) if T is a class type, the destructor call starts, or (1.5) the storage which the object occupies is released, or is reused by an object that is not nested within o ([intro.object]).

https://eel.is/c++draft/basic.life#1.2

Т.е. если всё сложить, то при перезаписи одного объекта в union, ты убиваешь (завершаешь жизнь) другого. А значит другой нельзя читать. Читать из него - то же самое, что читать из неинициализированной переменной. Такое же UB.

Добавлено через 2 минуты
А в Note 1 первой цитаты написано вот это:

Сообщение от TheCalligrapher Исключение в С++ сделано только для членов union, которые являются структурами с одинаковыми начальными последовательностями объявлений членов. Вот эти общие начальные последовательности можно просматривать, игнорируя соображения текущего активного члена. То есть вот так можно

Добавлено через 2 минуты

Сообщение от Verevkin это жэж начальный адрес данных, которые она (они) хранит (хранят)

Не, в C++ - это объекты сперва, а потом уже память. А в C++ нельзя читать из мёртвых объектов. Неважно каким способом ты их получил.
Если ты про это не слышал, то просто видимо не читал никакой серьезной литературы по С++.

1

Сообщение от ablex Т.е. если всё сложить, то при перезаписи одного объекта в union, ты убиваешь (завершаешь жизнь) другого.

Но поля-то статические, под них выделена память на всё время жизни переменной, ёмаё. Разве время жизни полей не равно времени жизни всего union?

Как это работает на низком уровне-то?
Я понимаю, что там написано, но я не понимаю смысл этого, как это выглядит на практике. Вон у ТС даже картинка в вопросе есть. Как надо подкрутить настройки компилятора, чтобы пример стал выдавать неверный результат?

Добавлено через 4 минуты

Сообщение от ablex Если ты про это не слышал, то просто видимо не читал никакой серьезной литературы по С++.

Иногда меня терзают смутные сомнения, что всё, что написано в серьёзной литературе, правда.
Если взять в качестве примера наш текущий случай, то я ума не разложу, зачем так сделано? Чтобы было неудобно? Получается, что поля каким-то волшебным образом имеют разное время жизни, которое заранее неизвестно. Зачем?

0

Сообщение от Verevkin Первый раз такое слышу.

Ну это уж точно неправда. Тема уже миллион раз тут обсуждалась.

Сообщение от Verevkin Пруфы, хоть, дай.

Вперёд читать стандарт. Ключевые слова я дал: union, active member, lifetime.

Переключение активного члена union заканчивает lifetime предыдущего активного члена. Чтение объекта, чей lifetime закончился - неопределенное поведение. (12.3, 6.8)

Сообщение от Verevkin Ну, переменная типа union (и её поля) - это жэж начальный адрес данных, которые она (они) хранит (хранят).

Какие еще "адреса данных"? Какая разница, какие там адреса? Зачем вы вообще на них смотрите? Это все детали реализации, которые к языку С++ никакого отношения не имеют.

Сообщение от Verevkin Разве в С++ это не так?

Какая разница, так это или не так. Язык С++ говорит, что чтение неактивного члена union - неопределенное поведение. Какая разница, что там "определяет размеры"?

Добавлено через 10 минут

Сообщение от Verevkin Как это работает на низком уровне-то?

Что за набор слов? О какой "работе" (на любом уровне) может идти речь в случае неопределенного поведения?

Сообщение от Verevkin Я понимаю, что там написано, но я не понимаю смысл этого, как это выглядит на практике.

Продолжается поток бессмыслицы. О какой "практике" может идти речь в случае неопределенного поведения?

На практике неопределенное поведение существует для оптимизаций. Компилятор оптимизирует код в рамках уверенности, что неопределенное поведение никогда не происходит. В частности, если неукий код содержит безусловное неопределенное поведение (напр., запись в одно поле union и чтение из другого), значит эта ветвь программы никогда не будет выполняться и код для нее можно не генерировать вообще. А вы нам тут про какие-тот адреса рассказывать пытаетесь...

0

Сообщение от TheCalligrapher Какие еще "адреса данных"? Какая разница, какие там адреса? Зачем вы вообще на них смотрите? Это все детали реализации, которые к языку С++ никакого отношения не имеют.

Не понял. А как это тогда вообще работает?

0

Сообщение от Verevkin Иногда меня терзают смутные сомнения, что всё, что написано в серьёзной литературе, правда.

Программист должен уметь читать спецификацию.

Сообщение от Verevkin Чтобы было неудобно?

Нет, просто это не тот инструмент. Хочешь работать с памятью - есть другие средства, предназначенные специально для этого.

Сообщение от Verevkin зачем так сделано?

Чтобы все стройно работало. Если внутри union std::string и int, то такой код что тебе даст? Креш в лучшем случае.
Про strict aliasing почитай.
https://gist.github.com/shafik... ee272a58f8

ОДНАКО, не смотря на это, type punning через union все равно будет работать во многих компиляторах, потому что они (разрабы компиляторов) НАМЕРЕННО НЕ проводят оптимизации aliasing`а (оставляют поведение как в Си). Потому что многие программисты на Си продолжают тащить в Си++ этот приём, и это явление настолько массовое, что проще перестать соответствовать стандарту в этом моменте.

1

Сообщение от Verevkin Но поля-то статические, под них выделена память на всё время жизни переменной, ёмаё. Разве время жизни полей не равно времени жизни всего union?

Нет, конечно. Зачем выделять память под все поля, если в каждый момент времени активно только одно?

О какой вообще "памяти" вы вообще ведете речь? Что такое "выделена"? В С++ понятие "памяти" даже отдаленно не похоже на то, о чем вы здесь рассуждаете.

0

Сообщение от TheCalligrapher Какая разница, так это или не так. Язык С++ говорит, что чтение неактивного члена union - неопределенное поведение. Какая разница, что там "определяет размеры"?

Если в стандарте так написано, значит так и есть?
Напоминает мамкин ответ "потому что я так сказала!" на вопрос "почему?".
Я не спорю, я просто пытаюсь разобраться, правда ли это, и почему (и для чего) так сделано. А то получается, что в С++ авторы понапихали UB-ситуаций и считают, что проще подкорректировать под них стандарт, чем исключить.



Как же мне повезло, что на работе я сам выбираю, на чём писать софт.

0

Сообщение от Verevkin Не понял. А как это тогда вообще работает?

Не понимаю вопроса. В чем проблема с "работает"?

Вот я, например, положил в переменную значение 25, не менял ее, и затем прочитал. Компилятор вообще устранил эту переменную, потому что понял, что она всегда равна 25. То есть нет никакой памяти, и при этом все работает.

Где проблема?

0

Сообщение от TheCalligrapher Нет, конечно. Зачем выделять память под все поля, если в каждый момент времени активно только одно?

Поскольку поля находятся по одному адресу, нужно столько памяти, сколько занимает поле максимального размера. Разве это не логично? Компилятор, ведь, знает размер в момент компиляции.

Добавлено через 1 минуту

Сообщение от TheCalligrapher Вот я, например, положил в переменную значение 25, не менял ее, и затем прочитал. Компилятор вообще устранил эту переменную, потому что понял, что она всегда равна 25. То есть нет никакой памяти, и при этом все работает.

Это не наш случай. Вот если бы ты ничего не изменял, а прочитал бы мог бы прочитать вместо 25 значение 100500, то это UB.

0

Сообщение от Verevkin Если в стандарте так написано, значит так и есть?

Совершенно верно.

Сообщение от Verevkin Напоминает мамкин ответ "потому что я так сказала!" на вопрос "почему?".

Нет. Вот это ^^^ очень характерное заблуждение.

Ребенок задает маме вопросы об окружающем мире, который для ребенка (да и для опытного ученого) -непознанный объект исследований, проводимых фактически методом "чёрного ящика", то есть методом научного тыканья палкой и наблюдения реакции.

Язык С++ же не надо исследовать методом "черного ящика". Он не прилетел к нам с другой планеты на дискете. В него не надо тыкать палкой. Он полностью описан в стандарте и любая реализация - попытка идеально точно соблюсти требования стандарта.

Сообщение от Verevkin Как же мне повезло, что на работе я сам выбираю, на чём писать софт.

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

0

Сообщение от TheCalligrapher А подавляющем большинстве случаев это означает, что аффтар "пишет софт" на языке, который является продуктом его собственных домыслов чуть менее, чем полностью.

Да пусть, хотя бы, и так. Но аффтара это кормит. Чуть более, чем полностью.
-----
Не надо на личности переходить, это мы так щас до оскорблений опустимся. Не хочу.

0

Сообщение от Verevkin я просто пытаюсь разобраться, правда ли это, и почему (и для чего) так сделано.

Хошь разобраться - читай ссылку, которую я привел. Все остальное от лукавого.

0

Сообщение от Verevkin Поскольку поля находятся по одному адресу, нужно столько памяти, сколько занимает поле максимального размера. Разве это не логично? Компилятор, ведь, знает размер в момент компиляции.

Снова поток каких-то феерических домыслов.

"Адреса" в программе на С++ появляются только после того, как будет применен оператор взятия адреса &. Без этого никаких "адресов" не существует вообще. То же самое и с "размерами" (sizeof, адресная арифметика и т.п.). Без этого никаких размеров не существует вообще, максимальных или минимальных - неважно.

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

Сообщение от Verevkin Это не наш случай.

Это где я такое сказал? (Постарайтесь чтобы в будущем я не видел здесь подобных однострочных вбросов. Чтобы возражать мне в таких вопросах нужно подготовить странички три-четыре материала с отщывами рецензентов).

Как несложно догадаться, то, к чему я веду, в частности - это что union может располагаться в регистрах процессора и правильный менеджмент этих регистров определяется знанием о текущем активном члене union. Мой пример в том числе об этом.

А вы нам тут рассказываете сказки про какую-то "выделенную память", "максимальный размер", "располагаются на картинке" и т.п Ничего этого в С++ нет и никогда не было. Это пионэрские домыслы.

0

Сообщение от ablex Хошь разобраться - читай ссылку, которую я привел. Все остальное от лукавого.

За ссылку спасибо.
Раньше я понимал работу union как-то так:



Пойду чаёк заварю...

0

Сообщение от Verevkin . Раньше я понимал работу union как-то так:

Вот именно такие попытки "понимать" С или С++ через разглядывание сгенерированного машинного кода - это и есть метод "тыканья палкой" в компилятор. Если "ученый" не обладает великолепным знанием стандарта языка, то такое разглядывание приведет лишь к рождению феерических теорий, вроде "безногий таракан не слышит" из известного анекдота.

0

Сообщение от TheCalligrapher Снова поток каких-то феерических домыслов.

Пусть это домыслы, но они основаны на практике. Разве sizeof(тип) может вернуть разные размеры в зависимости от его положения в коде?

Сообщение от TheCalligrapher Вот именно такие попытки "понимать" С или С++ через разглядывание сгенерированного машинного кода - это и есть метод "тыканья палкой" в компилятор. Если "ученый" не обладает великолепным знанием стандарта языка, то такое разглядывание приведет лишь к рождению феерических теорий, вроде "безногий таракан не слышит" из известного анекдота.

Согласен, пусть это так. Я не учёный, я рабочий. Ответ "так нельзя, потому что это написано в Писании стандарте", меня не устраивает. Я смотрю в сгенерированный машинный код и вижу, что "она вертится".
---------
Пойду спать. Всем спасибо за дискуссию.

0

Сообщение от Алексей1153 union задуман как возможность поэкономить озу. А для реинтерпретации есть memcpy

Почитался я вашу полемику насчёт union. Тут я за Verevkin-а.
Использовать для реинтерпретации memcpy, да даже и приведение типа указателей к другому типу, ничем не менее безопасно чем union-ы. А memcpy ещё и затратно по времени и памяти.

Сообщение от TheCalligrapher Исключение в С++ сделано только для членов union, которые являются структурами с одинаковыми начальными последовательностями объявлений членов.

Пример где, как раз, начальные последовательности разные.

И это не MS такие неправильные, применение union широко распространено когда мы только в динамике узнаём тип данных.

Согласен что использование union опасно, увеличивает вероятность ошибки. Но альтернативы - reinterpret_cast, сырые указатели, ни чем не лучше.

0