Unie i niezdefiniowane zachowanie w C++17

Cześć.

Poniższy program drukuje:
1
2
1
2

Czy zawiera on niezdefiniowane zachowanie, gdy bierzemy pod uwagę standard C++17?

The union is only as big as necessary to hold its largest data member. The other data members are allocated in the same bytes as part of that largest member. The details of that allocation are implementation-defined, and it's undefined behavior to read from the member of the union that wasn't most recently written. Many compilers implement, as a non-standard language extension, the ability to read inactive members of a union.

źródło

EDIT: powód to pewnie (jak to w 99% bywa) zła nazwa.

Kolego, który przeniosłeś ten wątek. Kultura wymaga, aby podać powód przeniesienia. Skoro człowiek posługujący się skrzynką bjarne@stroustrup.com był w stanie ustosunkować się do mojego pytania, to ty tym bardziej powinieneś, skoro gmerasz przy wątku.

it's undefined behavior to read from the member of the union that wasn't most recently written -> struktury z przykładu mają common initial sequence, więc można czytać nieaktywne pola union

Kultura wymaga, by zapoznać się z zasadami zakładania tematów. Jak chcesz powód, to proszę: Brak formatowania. Brak opisu - podałeś kod i pytasz czy jest poprawny, zawężając tylko pytanie do UB. Z perspektywy czasu taki temat jest bezużyteczny i do właśnie takiego działu trafił.

No tak, podałem kod i pytam, czy jest poprawny. Szczyt bezczelności. A co byś chciał? Mam ci tutaj wkleić 30 nagłówków i napisać opis dziedzinowy na 30 stron? Kolego, kod jest przejrzysty, zawiera meritum, więc nie mydl mi oczu formatowaniem. Jeżeli uważasz, że pytania dotyczące UB są bezużyteczne, to nie mamy o czym rozmawiać. Poczytaj sobie np. o UBSan. Korporacja Google nie utworzyłaby takiego narzędzia, gdyby UB było sprawą marginalną.

Na http://en.cppreference.com/w​/cpp/language/data_members mamy:

"If a standard-layout union holds two (or more) standard-layout structs as members, and these structs have a common initial sequence of data members, it is well-defined to examine any member of that common initial sequence regardless of which member of the union is active."

Ciekawe podejście. Widzę, że C++ zmierza w stronę paradygmatu funkcyjnego. Ciekawe, czy w C++20 będzie kacza typizacja (ang. duck typing)? Bo to, co podajesz, to w sumie jest coś takiego: nazwa może być inna, byle typy się zgadzały - jak coś wygląda jak kaczka (pola) i kwacze jak kaczka (metody), to znaczy, że to jest kaczka (obiekt danego typu) i można go tak traktować. W tym przypadku to samo dotyczy unii. Nie wiem, czy to jest zgodne ze standardem, ale domyślam się, do czego takie podejście może prowadzić.

Jak chcesz powód, to proszę: Brak formatowania.

Pewnie chodziło o to, aby kod był w znacznikach [cpp]tutaj kod źródłowy[/cpp].

Brak opisu - podałeś kod i pytasz czy jest poprawny, zawężając tylko pytanie do UB. Z perspektywy czasu taki temat jest bezużyteczny i do właśnie takiego działu trafił.

Uważam, że to pytanie jest dość istotne. Jeśli można tak pisać, to znaczy, że mamy coś w rodzaju wcześniej opisanej kaczej typizacji dla unii. A jak nie, to w praktyce trzeba napisać więcej bardziej skomplikowanego kodu, aby osiągnąć to samo.

_Dopisano:
@ktokolwiekMającyUprawnienia: zmienić tytuł na jakiś lepszy, choćby "Kacza typizacja w uniach" (nie miałem lepszego pomysłu), dorzucić formatowanie do pierwszego postu i wyciągnąć ten temat z bezużytecznych. Nie kojarzę, abyśmy mieli podobny temat na forum, a to może być przydatne choćby przy omawianiu rodzajów typizacji w kursie (jeśli coś takiego jest planowane).