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

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

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

0

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

Расскажите недолго, вкратце, почему это трэшак.
То есть не насыпать терминов вроде "текущего активного члена" никак не реализованного ни в одном компиляторе С++, а толково объяснить почему использование union для реинтерпретации данных плохо по сравнению с такими то и такими то способами.
Критериев плохого кода множество. Рассмотрим самые важные и проверяемые
1. В коде возникает UB. При корректном использовании union, в том числе для реинтерпретации данных UB не возникает, г-кодеры получают деньги а не рекламации.
2. Код медленный или требует большего расхода памяти. Как, вроде бы разобрались выше, использование std::memcpy требует двух машинных команд, да ещё нужно куда то скопировать, т.е. нужно создать переменную. В случае union можно никуда не копировать. Заполнили union через один член и сразу доступен другой член требуемого типа. Т.е. по п.2. union выигрывает.
И так, почему вы считаете это трэшем?

Сообщение от TheCalligrapher То есть опять совершенно непонятно, о чем вы ведете речь.

То есть, если не знаете что ответить то отвечаете что вам непонятно. Я заметил, но это не делает вас правыми.

Сообщение от TheCalligrapher О каком "никакого UB у меня там нет", если спецификация языка говорит, что есть?

Она там может быть если мы не знаем что творим, компилятор нам не может гарантировать что его не будет. Например, можно ошибиться в порядке байт представления числа или его размере. Это же справедливо и для варианта с std::memcpy.

Сообщение от TheCalligrapher Все мои высказывания до сих пор были посвящены теме активного/неактивного члена union. Это высказывание тоже

А ещё вы в нём высказываете (я специально цитирую то что цитирую, акцент на этом).

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

А если одинаковые не начальные последовательности объявлений членов то непременно UB?

Сообщение от TheCalligrapher Каждый такой флуд вам придется подробно объяснять. Начнем с ссылки на сайт MS. Итак? (И еще раз: если мой вопрос явно не помечен как риторический, ответ обязателен. Игнорировать заданные мнюю вопросы здесь не принято.)

Предлагаю вам перечитать правила форума несколько раз, это успокаивает.
После этого ответьте, пожалуйста, если вас не затруднит, на заданные мной вопросы по существу про union и его применимость к другим случаям нежели чем для экономии памяти.

0

Сообщение от Curry использование std::memcpy требует двух машинных команд, да ещё нужно куда то скопировать, т.е. нужно создать переменную. В случае union можно никуда не копировать. Заполнили union через один член и сразу доступен другой член требуемого типа. Т.е. по п.2. union выигрывает.

всё не так, показанное - для -O0.
Для -O3 машинные команды будут одинаковые: https://godbolt.org/z/r3MxzTq7M

Но это вот именно здесь повезло, что они одинаковые. Стандарт этого не обещает. Стандарт говорит, что с union такое не гарантировано

0

Сообщение от Алексей1153 всё не так

Так почему union то нельзя использовать? А если у нас большая структура не влезающая в регистр?

0

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

0

Сообщение от Curry То есть не насыпать терминов вроде "текущего активного члена" никак не реализованного ни в одном компиляторе С++,

Вы постоянно несете поток из какого-то словесного салата, которая, наверное, накрывает участников форума приступами смеха. Что такое "реализация в компиляторе С++", когда речь идет о неопределенном поведении? Что такое "реализация неопределенного поведения"? Что вы пытаетесь сказать?

Сообщение от Curry Критериев плохого кода множество. Рассмотрим самые важные и проверяемые 1. В коде возникает UB.

Готово. О чем спор тогда?

Сообщение от Curry г-кодеры получают деньги а не рекламации.

"Аргумент" ))

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

Сколько мы уже видели таких порок, да чуть ли не мирового масштаба...

"Знаковые типы просто заворачиваются, никакого UB" Затем: strict overflow semantics, дикие вопли и звуки порки с конюшен, запах пригорелых задниц. Овнари, усвоив науку, прячутся по норам, пока не заживут пятые точки...
Потом "реинтерпретауия через указатель всегда работает, никакого UB" Затем: strict aliasing semantics, дикие вопли и звуки порки с конюшен, запах пригорелых задниц. Овнари, усвоив науку, прячутся по норам, пока не заживут пятые точки...
Потом "memcpy всегда копирует слева направо, можно копировать перекрывающиеся регионы, никакого UB". Затем: известный скандал с обратным memcpy, дикие вопли и звуки порки с конюшен, запах пригорелых задниц. Овнари, усвоив науку, прячутся по норам, пока не заживут пятые точки...

Как говорится, вы сейчас здесь.

И вышеописанная живописная эволюция относится именно к г-проектам, эволюционировавшим в что-то более респектабельное. Если же проект с самого начала г-проектом не был, то на конюшню за такое обращение с union вы улетите сразу, не дожидаясь появления некоего "strict active membеr semantics" в каком-нибудь GCC.

Сообщение от Curry При корректном использовании union, в том числе для реинтерпретации данных UB не возникает

После того, как пятидесятый раз очередного г-кодера тыкают носом с спецификацию языка, где черным по белому написано, что такой код вызывает UB, но наука не прививается - в какой-то момент, с сожалению, придется решить, что данный персонаж достиг физически обусловленного потолка в своем развитии и любые дальнейшие попытки бесполезны.

Либо вы способны к обучению, либо нет. И в нынешнем состоянии можно уже с уверенностью говорить, что надежда на какое-то обучение возможна только после полного вытравливания из бошки всей той чуши, которая там окопалась. До состояния tabula rasa. То есть с нуля. Без этого толку не будет.

Сообщение от Curry 2. Код медленный или требует большего расхода памяти. Как, вроде бы разобрались выше, использование std::memcpy требует двух машинных команд, да ещё нужно куда то скопировать, т.е. нужно создать переменную. В случае union можно никуда не копировать. Заполнили union через один член и сразу доступен другой член требуемого типа. Т.е. по п.2. union выигрывает.

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

Но это не более чем болтовня "ни о чем", через которую г-кодерные тролли пытаются увести разговор от темы. Реинтерпретация через union - UB. То есть никакого осмысленного кода она не порождает.

Сообщение от Curry А если одинаковые не начальные последовательности объявлений членов то непременно UB? Кликните здесь для просмотра всего текста C++ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 struct Impact {     double direction[3];     int    count;     double power; };   struct ImpactXYZ {     double x,y,z;     int _unused;     double power; };   union my_union {     Impact      i;     ImpactXYZ   ixyz; };

И снова... Что я должен увидеть в этом наборе объявлений?

---

Участникам форума: кто-нибудь может мне внятно объяснить, что данный аффтар хочет сказать вот этими стенами объявлений, которые он флудпостит уже третий раз. Первой была ссылка на майкрософт в сообщении #40. Любые попытки получить от него какие-то объяснения пока приводили лишь к очередному флуду из очередного набора объявлений.

Что это? Это какой-то глюк? Глюк человека? Глюк AI-бота? Мне искренне интересно.

0

Меня всегда удивлял этот подход: придумывать свои собственные способы что-то сделать в обход официальной инструкции. Интересно, это во всём так? Ну типа, купили тостер и там в инструкции описан порядок действий, но мы инструкцию не читаем, а сразу делаем как нам нравится. Забавляет потом читать отзывы, когда человек ругает этот тостер, потому что он плохо работает. При этом при эксплуатации он нарушил все мыслимые правила, описанные производителем.
И этот феерический аргумент: "инструкцию пишут дурачки, я-то лучше знаю, у меня этих тостеров уже 10 штук было".

Что вот сложного в этом? В языке оставили возможность оптимизации для сгенерированого кода, эта возможность описана и документирована. Не важно, используется она сейчас или нет. Не важно, пошёл ли производитель компилятора на поводу у юзеров и не стал использовать эту возможность, или не пошёл. Всё равно она есть. Это, блин, так трудно прочитать о ней, и не применять её превратно? Обязательно нужно домысливать и извращать идею? Мне не понятно.

0

Сообщение от ablex Меня всегда удивлял этот подход: придумывать свои собственные способы что-то сделать в обход официальной инструкции. Интересно, это во всём так? Ну типа, купили тостер и там в инструкции описан порядок действий, но мы инструкцию не читаем, а сразу делаем как нам нравится. Забавляет потом читать отзывы, когда человек ругает этот тостер, потому что он плохо работает. При этом при эксплуатации он нарушил все мыслимые правила, описанные производителем. И этот феерический аргумент: "инструкцию пишут дурачки, я-то лучше знаю, у меня этих тостеров уже 10 штук было".

Меня всегда удивляло, зачем разработчики компилятора С++ добавили в него возможность возникновения UB. Да ещё и задокументировали. Ведь, для чего-то это им было нужно, да? А для чего? Какие от этого плюсы и бонусы? Минусы UB, как раз таки очевидны, а польза - нет. Я, как работяга, не могу этого понять. Объясните мне, как представителю рабочего класса, пожалуйста. Очень вас прошу.

0

Сообщение от Verevkin зачем разработчики компилятора С++ добавили в него возможность возникновения UB.

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

UB - это не какая-то процедура, которая вдруг возникает и все портит. Это ситуация (чаще всего маргинальная и нелогичная по своей сути), которую допустил программер и по поводу которой язык не дает никаких гарантий.

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

0

Сообщение от ablex Это неточная трактовка. Не "добавили возможность", а "некоторые маргинальные случае намеренно не специфицировали".

Ладно, я по-другому сформулирую. По-человечески. Зачем некоторые все маргинальные случаи просто не выпилили нахрен? Со стороны это выглядит как "да, мы тут накосячили, но задокументировали наши косяки, поэтому, если что, RTFM". Я, как работяга, понимаю это именно так. Бороться c этим я не собираюсь (это бесполезно), остаётся это только освистывать и высмеивать.

З.Ы. Я где-то читал, что С++ создали ради шутки, по приколу... Не думаю, что это правда, но иногда меня терзают смутные сомнения. ©

0

Verevkin, разработчики не добавили UB, они наоборот убрали у компилятора даже мысль, что UB существует. Чтобы компилятор мог сделать код эффективнее.

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

Добавлено через 40 секунд

Сообщение от Verevkin Я где-то читал, что С++ создали ради шутки

нет, его создали ради ООП

0

Сообщение от Алексей1153 Пример из жизни: вот режешь ножом колбасу. Подставлять палец - это UB. Но нож про это не в курсе, он просто эффективно режет. Если бы нож на каждый чих проверял, не палец ли ему там подставили, то резать колбасу было бы неудобно, нож бы просто доставал предупреждениями. А то ещё и исключениями бы кидался

Плохой пример. Это пример интерпретатора, а не компилятора.

0

Verevkin, вот! Всё верно. Потому трансляторы и делятся на интерпретаторы и компиляторы

0

Сообщение от Алексей1153 трансляторы и делятся на интерпретаторы и компиляторы

Да я и не возражаю.
Но пример-то плохой. С++ - это не интерпретатор.

1

Verevkin, C++ - это язык, да

А в чём плохость примера, я так и не понял. Он именно про компилятор для C++

0

Сообщение от Алексей1153 А в чём плохость примера, я так и не понял.

При возможности подсовывания пальца под нож во время нарезки колбасы [хороший] компилятор запретит брать нож в руки. Ну, или, хотя бы, обматерит обладателя пальцев. Грубовато, но как-то так.
-------
Пора закруглять этот флуд. Мне надоело, дома дел полно.

0

Сообщение от Verevkin Пора закруглять этот флуд.

Ну это будет каллиграфер решать, когда закруглять, а когда заострить. Проблемы белых людей нас не касаются.

0

Verevkin, это больше похоже на поведение интерпретатора, там не жалеют проверок. Или отладочный режим. В общем, это снижает эффективность выполнения кода

0

Сообщение от Verevkin "да, мы тут накосячили, но задокументировали наши косяки, поэтому, если что, RTFM"

Ну типа, выход на границы массива - это UB. Потому что постоянно проверять диапазон доступа - это накладно. В чём тут косяк? Есть языки, которые проверяют. Например C# проверяет, потому что у него там виртуальная машина и она знает контекст (в отличие от CPU) выполнения и может делать такие проверки. Естественно любая виртуализация - это не бесплатно. Или какой-нить Python тоже проверяет, ну потому что он интерпретатор и ему всё равно надо всё загружать, не проверять в его случае - это экономия на спичках. А C++ - не проверяет, потому что "нада производительность". А ежели кто будет пользоваться тем, что не проверяет - ну тогда этот "кто" сам дурак, язык ничего в этом случае не гарантирует -то бишь UB.

Хотя, видишь ли, все твои ответы говорят о том, что ты не собираешься ни в чём разбираться, что ты всё уже для себя решил и пришел просто повысмеивать что-то там. Какой смысл распинаться, если даже самый логичный довод ничего не переменит? Ты ж взрослый человек, работяга, как ты можешь заблуждаться в чем-то, у тебя ж опыт ого-го, и задач ты решил тьму, и, главное, заработал на этом, так ведь? Никакой аноним с форума ничего тут не изменит.

Я по этой причине особо тут не отвечаю, ибо люди неблагодарные скотины. Ты на них кучу времени убьешь, а они тебе "я тут пришёл повысмеивать". Ну и пошёл ты нахер тогда, ды?

0

Сообщение от ablex Ну типа, выход на границы массива - это UB.

Ненененене!!!
У нас другая тема, товарищ. Извольте не забывать о ней.

0

Ты сам тему перевёл в общее русло:

Сообщение от Verevkin Меня всегда удивляло, зачем разработчики компилятора С++ добавили в него возможность возникновения UB.

Тут речь шла про UB вообще, а не про конкретное UB. Я в общем русле тебе и отвечаю и привожу наглядные примеры.

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

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

Поэтому (безадресно - если что):
- знать что это UB, не спорить и не ехидствать - это норм, даже если всё равно продолжаешь юзать абъюз в коде, ты делаешь это сознательно и со всей ответственностью.
- ничего не хотеть знать и юзать его потому что искренне полагаешь, что этот код хороший - не норм

1