Union что из себя представляет?

Читал много книг и там про него не чего не было сказано, парни объясните мне пожалуйста для чего он?

0

Сообщение от silent_1991 И тем не менее, книжка "UNIX разработка сетевых приложений" - не стандарт языка, не правда ли?

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

Сообщение от silent_1991 стандарт говорит, что подобное действие - UB

Кстати, с хода не нашёл, где он такое говорит?

0

easybudda, там где-то есть о том что читать без проблем можно только то что писалось последним. Вот цитата из:
http://en.cppreference.com/w/cpp/language/union
там говорят:

it's undefined behavior to read from the member of the union that wasn't most recently written.

может и не врут.

0

Сообщение от IGPIGP может и не врут.

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

0

Ы

9.5 Unions 1. In a union, at most one of the non-static data members 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: 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 (9.2), and if an object of this standard-layout union type contains one of the standard-layout structs, it is permitted to inspect the common initial sequence of any of standard-layout struct members; see 9.2. — end note ] ...

Кстати, такая гарантия раньше только для POD был, а теперь для standard-layout.

1

Сообщение от easybudda интересно только, какие с этим могут проблемы возникнуть?

easybudda, совершенно с Вами солидарен. Однако соображения:

Сообщение от Evg Вообще эта тема несколько раз уже проскакивала на форуме. Есть такое понятие, которое на бытовом языке называется "strict aliasing rules".

имеют место быть. Компиляторы уверены, что что два разных объекта не могут иметь один и тот же адрес.
Это похоже на заговор.

0

Сообщение от Evg В стандарте конкретно таких слов нету, но есть некий смысл, из которого следует, что указатели на разные типы данных, исключая указатель на char*, должны смотреть на разную память.

9.3.1 ... All non-static data members of a union object have the same address.

Сообщение от silent_1991 И оговорка о том, что стандарт говорит, что подобное действие - UB, здесь вполне уместна.

Вы воду льёте.

Сообщение от easybudda где он такое говорит?

Я не то что не верю, просто я нигде об этом не слышал, как и многие другие. Дайте ссылку на пункт в стандарте.

1

Сообщение от castaway All non-static data members of a union object have the same address.

Yes them have. Однако надёжно читать можно только последний из записанных. Так говорят боги Килдык...

1

Сообщение от IGPIGP Однако надёжно читать можно только последний из записанных.

Из чего это следует?

Сообщение от IGPIGP Так говорят боги Килдык...

Это те, кто что-то уверенно утверждает в этой теме не приводя ссылок на стандарт?)

0

Сообщение от castaway Это те, кто что-то уверенно утверждает в этой теме не приводя ссылок на стандарт?)

Дык у большинства же в лучшем случае копия черновика... А там... Ну вот из того что уже обсуждалось о нарушении strict alliasing:
Как сохранить float в переменной типа char?
Стандарт - не открытый ресурс и сослаться на него, строго говоря, невозможно.

0

Сообщение от easybudda где он такое говорит?

Там есть определенная тонкость.
В стандарте нет описания того что бывает при нарушении

In a union, at most one of the non-static data members 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.

кроме уточнения:

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 (9.2), and if an object of this standard-layout union type contains one of the standard-layout structs, it is permitted to inspect the common initial sequence of any of standard-layout struct members;

при этом в разделе про UB написано:

Undefined behavior may also be expected when this International Standard omits the description of any explicit definition of behavior.

Вот и делайте выводы

0

Сообщение от DrOffset Вот и делайте выводы

Может своими поделитесь?

0

Сообщение от easybudda Может своими поделитесь?

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

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

0

Сообщение от DrOffset Стандарт по сути задекларировал, что любое явно неописанное поведение - непределенное.

Вообще, система в которой всё что не запрещено, - разрешено, имеет потенциал развития значительно более высокий чем та, у которой всё что не разрешено, - запрещено.

Сообщение от DrOffset Однако такое лучше не обсуждать в разделе для новичков, а то они еще подумают, что им все можно

А как же экспериментировать с набиванием собственных шишек? Новичкам стандарт не писан (имхо)

Сообщение от DrOffset кроме уточнения:

DrOffset, как мне удалось перевести и спарсить тут речь о типах одной иерархии. То есть когда оба типа содержат общую цепь байт вначале (инициализированную одной последовательностью конструкторов). Это правильный вывод?

0

Сообщение от IGPIGP Вообще, система в которой всё что не запрещено - разрешено, имеет потенциал развития значительно более высокий чем та у которой всё что не разрешено - запрещено.

Это вопрос философский.
Впрочем, UB ничего не запрещает. UB - это всего лишь отсутствие стандартизированного поведения. Некоторые проявления UB вполен себе безобидные и контролируются в частных случаях. Например, лезть за пределы выделенной памяти - UB, но если мы конкретно знаем устройство нашего аллокатора, и в курсе, что он помещает информацию по определенному смещению от начала выделенной нам памяти, то вполне сможем эту информацию прочитать, и программа после этогого хоть и станет непортируемой и потеряет в сопровождаемости, но поведение, заложенное нами в рамках текущей реализации сохранится и будет работать.
Почему у многих здесь (как и у меня) негативное отношение к UB (даже если оно контролируемо в данный момент), так это потому, что многие (как и я) - занимаются программированием профессионально. И здесь, помимо собственно программирования, принято еще учитывать риски, в том числе на сопровождение кода. Наличие UB этот риск увеличивает. Поэтому в профессиональной разработке принято строго придерживаться установленного в компании регламента на кодирование и стандартов, чтобы получить более предсказуемый цикл разработки ПО.

Сообщение от IGPIGP как мне удалось перевести и спарсить тут речь о типах одной иерархии.

Скажем так, тут речь просто о совместимых по своему представлению типах. Например две структуры, с одинаковым порядком совпадающих полей.
Например, типы int * и int уже не являются layout-compatible.

3.9

11 Two types cv1 T1 and cv2 T2 are layout-compatible types if T1 and T2 are the same type, layout-compatible enumerations (7.2), or layout-compatible standard-layout class types (9.2).

9.2

16 The common initial sequence of two standard-layout struct (Clause 9) types is the longest sequence of nonstatic data members and bit-fields in declaration order, starting with the first such entity in each of the structs, such that corresponding entities have layout-compatible types and either neither entity is a bit-field or both are bit-fields with the same width. [ Example: C++ 1 2 3 4 5 struct A { int a; char b; }; struct B { const int b1; volatile char b2; }; struct C { int c; unsigned : 0; char b; }; struct D { int d; char b : 4; }; struct E { unsigned int e; char b; }; The common initial sequence of A and B comprises all members of either class. The common initial sequence of A and C and of A and D comprises the first member in each case. The common initial sequence of A and E is empty. —end example ] 17 Two standard-layout struct (Clause 9) types are layout-compatible if their common initial sequence comprises all members and bit-fields of both classes (3.9).

1

Сообщение от DrOffset Это вопрос философский. Впрочем, UB ничего не запрещает.

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

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

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

0

Сообщение от IGPIGP Компиляторы уверены, что что два разных объекта не могут иметь один и тот же адрес

Дело тут не в объектах. Пока внутри одной функции строятся обращения к разным полям одного и того же union'а, даже плохой компилятор постфактум в этом разберётся и ничего не напортачит. В реальности всё это вертится вокруг взятия адреса на поля union'а. В примере типа

имеем обращения по двум указателям: запись по указателю p2 и чтение по указателю p1. Опираясь на Strict aliasing rules компилятор вправе переставить местами операции чтения и записи в память, т.к. эти самые strict aliasing rules говорят о том, что обращения по указателям типа int* и float* обязаны иметь непересекающиеся адреса (т.е. независимые обращения) и следить за этим должен программист. Другими словами, если построить вызов функции

то нет никакой гарантии, что в i будет записано нулевое значение, потому что внутри функции foo компилятор может переставить местами чтение из p1 (т.е. из поля u.i) и запись в p2 (т.е. в поле u.f). Это именно с точки зрения стандарта. Хотя постфактум на современных компиляторах данный код отработает именно так, что в i будет записан 0

2

Evg, спасибо, - хороший пример. Но вот это:

Сообщение от Evg т.к. эти самые strict aliasing rules говорят о том, что обращения по указателям типа int* и float* обязаны иметь непересекающиеся адреса

разве это не:

Сообщение от IGPIGP Компиляторы уверены, что что два разных объекта не могут иметь один и тот же адрес.

(грубо говоря)?

0

Тут всё-таки речь идёт о полях объекта, а не о самих объектах. Да и для компилятора всё просто, когда он видит объекты. Все сложности анализов растут в случаях, когда есть только указатель, но не видны сами объекты

0

-Так он же болгарин!
– Какая разница?!
(х/ф "Брат2")

Сообщение от Evg Тут всё-таки речь идёт о полях объекта, а не о самих объектах.

Поля объекта это же объекты.
Там выше я давал ссылку на обсуждение strict alliasing при наличии двух разнотипных указателей на один и тот же объект участок памяти. Там приводится пример из хабра:
https://habrahabr.ru/post/114117/
Не суть. Думаю мы об одном говорим.

1

Сообщение от IGPIGP https://habrahabr.ru/post/114117/

Хорошая статья. В ней правда не хватает одного полезного совета. При использовании gcc в более-менее сложном проекте опция -fno-strict-aliasing помогает избавиться от головной боли (ценой небольшой потери производительности)

1