Cel związków w C i C ++

Wcześniej korzystałem ze związków zawodowych; dzisiaj byłem zaniepokojony, gdy przeczytałem ten post i dowiedziałem się, że ten kod

union ARGB
{
    uint32_t colour;

    struct componentsTag
    {
        uint8_t b;
        uint8_t g;
        uint8_t r;
        uint8_t a;
    } components;

} pixel;

pixel.colour = 0xff040201;  // ARGB::colour is the active member from now on

// somewhere down the line, without any edit to pixel

if(pixel.components.a)      // accessing the non-active member ARGB::components

jest w rzeczywistości nieokreślonym zachowaniem, to znaczy czytanie od członka związku innego niż ten, do którego ostatnio napisano, prowadzi do nieokreślonego zachowania. Jeśli nie jest to zamierzone użycie związków, co to jest? Czy ktoś może wyjaśnić to szczegółowo?

Aktualizacja:

Chciałem wyjaśnić kilka rzeczy z perspektywy czasu.

• Odpowiedź na pytanie nie jest taka sama dla C i C ++; moje nieświadome młodsze ja oznaczyło to jako C i C ++.
• Po przejrzeniu standardu C ++ 11 nie mogłem definitywnie stwierdzić, że wywołuje on dostęp / inspekcję nieaktywnego członka związku jest niezdefiniowany / nieokreślony / zdefiniowany w implementacji. Wszystko, co mogłem znaleźć, to §9.5 / 1:

  Jeśli unia układu standardowego zawiera kilka struktur o układzie standardowym, które mają wspólną sekwencję początkową i jeśli obiekt tego typu ułożenia standardowego układu zawiera jedną ze struktur układu standardowego, dozwolone jest sprawdzenie wspólnej sekwencji początkowej dowolnej elementów struktury o standardowym układzie. § 9.2 / 19: Dwie struktury o standardowym układzie mają wspólną sekwencję początkową, jeśli odpowiadające elementy mają typy zgodne z układem i żaden z nich nie jest polem bitowym lub oba są polami bitowymi o tej samej szerokości dla sekwencji jednego lub więcej początkowych członkowie.

• Będąc w C, ( C99 TC3 - DR 283 i nowsze) jest to legalne ( podziękowania dla Pascala Cuoqa za podniesienie tego). Jednak próba zrobienia tego może nadal prowadzić do nieokreślonego zachowania , jeśli odczytana wartość okazuje się być niepoprawna (tak zwana „reprezentacja pułapki”) dla typu, przez który jest czytana. W przeciwnym razie odczytana wartość jest zdefiniowana jako implementacja.

• C89 / 90 wywołało to w nieokreślonym zachowaniu (załącznik J), a książka K&R mówi, że jego implementacja jest zdefiniowana. Cytat z K&R:

  Taki jest cel unii - pojedynczej zmiennej, która może zgodnie z prawem posiadać dowolny z kilku typów. [...] tak długo, jak użytkowanie jest spójne: pobrany typ musi być typem ostatnio zapisanym. Obowiązkiem programisty jest śledzenie, który typ jest obecnie przechowywany w związku; wyniki zależą od implementacji, jeśli coś jest przechowywane jako jeden typ i wyodrębniane jako inny.

• Wyciąg z TC ++ PL Stroustrupa (moje wyróżnienie)

  Użycie związków może być kluczowe dla zgodności danych [...] czasami niewłaściwie wykorzystywanych do „konwersji typu ”.

Przede wszystkim to pytanie (którego tytuł pozostaje niezmieniony od mojego pytania) zostało postawione z zamiarem zrozumienia celu związków ORAZ nie na temat tego, co pozwala standard. Np. Używanie dziedziczenia do ponownego użycia kodu jest oczywiście dozwolone przez standard C ++, ale nie było to celem ani pierwotną intencją wprowadzenia dziedziczenia jako funkcji języka C ++ . To jest powód, dla którego odpowiedź Andreya pozostaje nadal akceptowana.

Cel związków jest raczej oczywisty, ale z jakiegoś powodu ludzie dość często tęsknią.

Celem unii jest oszczędzanie pamięci przy użyciu tego samego regionu pamięci do przechowywania różnych obiektów w różnych momentach. Otóż ​​to.

To jest jak pokój w hotelu. Różni ludzie żyją w nim przez nie nakładające się okresy. Ci ludzie nigdy się nie spotykają i na ogół nic o sobie nie wiedzą. Stosownie zarządzając podziałem czasu między pokojami (tj. Upewniając się, że różne osoby nie zostaną przypisane do jednego pokoju w tym samym czasie), stosunkowo niewielki hotel może zapewnić zakwaterowanie stosunkowo dużej liczbie osób, a to właśnie hotele są dla.

To właśnie robi związek. Jeśli wiesz, że kilka obiektów w twoim programie przechowuje wartości z nie nakładającymi się okresami istnienia wartości, możesz „scalić” te obiekty w jedność, a tym samym zaoszczędzić pamięć. Podobnie jak pokój hotelowy ma co najwyżej jednego „aktywnego” najemcę w każdym momencie, związek ma co najwyżej jednego „aktywnego” członka w każdym momencie programu. Można odczytać tylko „aktywnego” członka. Pisząc do innego członka, przełączasz status „aktywnego” na tego innego członka.

Z jakiegoś powodu ten pierwotny cel związku został „zastąpiony” czymś zupełnie innym: napisaniem jednego członka związku, a następnie sprawdzeniem go za pośrednictwem innego członka. Ten rodzaj reinterpretacji pamięci (aka „typ punning”) nie jest prawidłowym zastosowaniem związków. Generalnie prowadzi to do niezdefiniowanego zachowania opisanego w C89 / 90 jako wytwarzające zachowanie zdefiniowane w ramach implementacji.

EDYCJA: Używanie związków do celów znakowania punktowego (tj. Pisanie jednego członka, a następnie czytanie innego) otrzymało bardziej szczegółową definicję w jednej z Corrigenda Techniczna do standardu C99 (patrz DR # 257 i DR # 283 ). Należy jednak pamiętać, że formalnie nie chroni to przed wpadnięciem w niezdefiniowane zachowanie poprzez próbę odczytania reprezentacji pułapki.

Możesz użyć związków do tworzenia struktur takich jak poniżej, które zawierają pole, które mówi nam, który składnik związku jest rzeczywiście używany:

struct VAROBJECT
{
    enum o_t { Int, Double, String } objectType;

    union
    {
        int intValue;
        double dblValue;
        char *strValue;
    } value;
} object;

Zachowanie jest niezdefiniowane z punktu widzenia języka. Weź pod uwagę, że różne platformy mogą mieć różne ograniczenia w zakresie wyrównania pamięci i endianizmu. Kod w dużym endianie w porównaniu z małą maszyną endian zaktualizuje wartości w strukturze inaczej. Naprawienie zachowania w języku wymagałoby użycia przez wszystkie implementacje tego samego endianizmu (i ograniczeń wyrównania pamięci ...) ograniczających użycie.

Jeśli korzystasz z C ++ (używasz dwóch tagów) i naprawdę zależy Ci na przenośności, możesz po prostu użyć struktury i dostarczyć ustawiającego, który pobiera uint32_t i ustawia pola poprzez operacje maski bitowej. To samo można zrobić w C z funkcją.

Edycja : Oczekiwałem, że AProgrammer napisze odpowiedź na głosowanie i ją zamknie. Jak zauważyły ​​niektóre komentarze, kwestia endianizmu jest rozpatrywana w innych częściach standardu, pozwalając każdej implementacji decydować o tym, co należy zrobić, a wyrównanie i dopełnienie można również traktować inaczej. Teraz ważne są tutaj ścisłe zasady aliasingu, do których pośrednio odwołuje się AProgrammer. Kompilator może przyjmować założenia dotyczące modyfikacji (lub braku modyfikacji) zmiennych. W przypadku unii kompilator może zmienić kolejność instrukcji i przenieść odczyt każdego składnika koloru nad zapisem do zmiennej koloru.

Najbardziej powszechne stosowanie unionregularnie natknąć się aliasing .

Rozważ następujące:

union Vector3f
{
  struct{ float x,y,z ; } ;
  float elts[3];
}

Co to robi? Umożliwia czysty, schludny dostęp do Vector3f vec;członków według dowolnej nazwy:

vec.x=vec.y=vec.z=1.f ;

lub przez całkowity dostęp do tablicy

for( int i = 0 ; i < 3 ; i++ )
  vec.elts[i]=1.f;

W niektórych przypadkach dostęp do nazwy jest najwyraźniejszą rzeczą, jaką możesz zrobić. W innych przypadkach, szczególnie gdy oś jest wybierana programowo, łatwiej jest uzyskać dostęp do osi za pomocą indeksu numerycznego - 0 dla x, 1 dla y i 2 dla z.

Jak mówisz, jest to ściśle niezdefiniowane zachowanie, choć będzie „działać” na wielu platformach. Prawdziwym powodem korzystania ze związków jest tworzenie rekordów wariantów.

union A {
   int i;
   double d;
};

A a[10];    // records in "a" can be either ints or doubles 
a[0].i = 42;
a[1].d = 1.23;

Oczywiście potrzebujesz także pewnego rodzaju dyskryminatora, aby powiedzieć, co faktycznie zawiera wariant. I zauważ, że w związkach C ++ nie ma większego zastosowania, ponieważ mogą one zawierać tylko typy POD - skutecznie te bez konstruktorów i destruktorów.

W C był to dobry sposób na implementację czegoś w rodzaju wariantu.

enum possibleTypes{
  eInt,
  eDouble,
  eChar
}


struct Value{

    union Value {
      int iVal_;
      double dval;
      char cVal;
    } value_;
    possibleTypes discriminator_;
} 

switch(val.discriminator_)
{
  case eInt: val.value_.iVal_; break;

W czasach małej pamięci struktura ta zużywa mniej pamięci niż struktura, która ma cały element.

Nawiasem mówiąc, C zapewnia

    typedef struct {
      unsigned int mantissa_low:32;      //mantissa
      unsigned int mantissa_high:20;
      unsigned int exponent:11;         //exponent
      unsigned int sign:1;
    } realVal;

aby uzyskać dostęp do wartości bitów.

Chociaż jest to ściśle niezdefiniowane zachowanie, w praktyce będzie działać z praktycznie każdym kompilatorem. Jest to tak szeroko stosowany paradygmat, że każdy szanujący się kompilator będzie musiał zrobić „właściwą rzecz” w takich przypadkach. Jest to z pewnością lepsze niż pisanie na maszynie, które może generować uszkodzony kod w niektórych kompilatorach.

W C ++, Boost Variant implementuje bezpieczną wersję unii, zaprojektowaną tak, aby w jak największym stopniu zapobiegać niezdefiniowanemu zachowaniu.

Jego wydajność jest identyczna z enum + unionkonstrukcją (stos przydzielony itp.), Ale używa listy typów szablonów zamiast enum:)

Zachowanie może być niezdefiniowane, ale to tylko oznacza, że ​​nie ma „standardu”. Wszystkie przyzwoite kompilatory oferują #pragmy do kontrolowania pakowania i wyrównania, ale mogą mieć różne ustawienia domyślne. Wartości domyślne zmienią się również w zależności od zastosowanych ustawień optymalizacji.

Związki służą nie tylko do oszczędzania miejsca. Pomagają nowoczesnym kompilatorom w pisowni czcionek. Jeśli reinterpret_cast<>wszystko, kompilator nie może przyjąć założeń na temat tego, co robisz. Być może będzie musiał wyrzucić to, co wie o twoim typie i zacząć od nowa (wymuszając zapis do pamięci, co jest obecnie bardzo nieefektywne w porównaniu do szybkości zegara procesora).

Technicznie jest niezdefiniowany, ale w rzeczywistości większość (wszystkich?) Kompilatorów traktuje go dokładnie tak samo, jak używając reinterpret_castjednego typu do drugiego, w wyniku czego zdefiniowano implementację. Nie przespałbym twojego aktualnego kodu.

Dla jeszcze jednego przykładu faktycznego użycia związków, struktura CORBA serializuje obiekty przy użyciu oznaczonego związku. Wszystkie klasy zdefiniowane przez użytkownika są członkami jednego (ogromnego) związku, a identyfikator liczby całkowitej mówi demarshallerowi, jak interpretować związek.

Inni wspominali o różnicach w architekturze (mało - duży endian).

Przeczytałem problem polegający na tym, że ponieważ pamięć zmiennych jest współdzielona, ​​to pisząc do jednej, inne się zmieniają i, w zależności od ich typu, wartość może być bez znaczenia.

na przykład. union {float f; int i; } x;

Pisanie do XI nie miałoby sensu, gdybyś czytał z XF - chyba że to jest to, co zamierzałeś, aby spojrzeć na znak, wykładnik lub mantysę elementów pływaka.

Myślę, że istnieje również problem z wyrównaniem: jeśli niektóre zmienne muszą być wyrównane ze słowami, możesz nie uzyskać oczekiwanego rezultatu.

na przykład. unia {char c [4]; int i; } x;

Gdyby hipotetycznie na jakimś komputerze znak musiał zostać wyrównany ze słowem, wówczas c [0] i c [1] współdzieli pamięć z i, ale nie c [2] i c [3].

W języku C, jak to zostało udokumentowane w 1974 r., Wszyscy członkowie struktury mieli wspólną przestrzeń nazw i zdefiniowano znaczenie „ptr-> członek” jako dodanie przesunięcia elementu do „ptr” i uzyskanie dostępu do adresu wynikowego za pomocą typu członka. Ten projekt umożliwił użycie tego samego ptr z nazwami prętów zaczerpniętymi z różnych definicji struktur, ale z tym samym przesunięciem; programiści używali tej zdolności do różnych celów.

Kiedy członom struktury przypisano własne przestrzenie nazw, niemożliwe stało się zadeklarowanie dwóch elementów struktury z tym samym przesunięciem. Dodanie związków do języka umożliwiło uzyskanie tej samej semantyki, która była dostępna we wcześniejszych wersjach języka (chociaż niemożność wyeksportowania nazw do otaczającego kontekstu mogła nadal wymagać użycia find / replace w celu zastąpienia elementu foo-> do foo-> type1.member). Ważne było nie tyle to, że ludzie, którzy dodali związki, mieli na uwadze jakieś szczególne przeznaczenie, ale raczej to, że zapewniają środki, dzięki którym programiści, którzy w każdym celu polegali na wcześniejszej semantyce , powinni nadal być w stanie osiągnąć ta sama semantyka, nawet jeśli musieliby do tego użyć innej składni.

Możesz użyć związku z dwóch głównych powodów:

1. Wygodny sposób na dostęp do tych samych danych na różne sposoby, na przykład w twoim przykładzie
2. Sposób na zaoszczędzenie miejsca, gdy istnieją różne elementy danych, z których tylko jeden może być „aktywny”

1 To naprawdę bardziej hack w stylu C do pisania skrótów na podstawie wiesz, jak działa architektura pamięci systemu docelowego. Jak już wspomniano, normalnie można go uciec, jeśli w rzeczywistości nie atakuje się wielu różnych platform. Wierzę, że niektóre kompilatory mogą pozwolić ci również używać dyrektyw pakowania (wiem, że robią to na strukturach)?

Dobry przykład 2. można znaleźć w typie VARIANT szeroko stosowanym w COM.

Jak wspomniano inni, związki w połączeniu z wyliczeniami i owinięte w struktury mogą być użyte do implementacji oznaczonych związków. Jednym praktycznym zastosowaniem jest implementacja Rust'a Result<T, E>, który pierwotnie jest implementowany przy użyciu czystego enum(Rust może przechowywać dodatkowe dane w wariantach wyliczania). Oto przykład w C ++:

template <typename T, typename E> struct Result {
    public:
    enum class Success : uint8_t { Ok, Err };
    Result(T val) {
        m_success = Success::Ok;
        m_value.ok = val;
    }
    Result(E val) {
        m_success = Success::Err;
        m_value.err = val;
    }
    inline bool operator==(const Result& other) {
        return other.m_success == this->m_success;
    }
    inline bool operator!=(const Result& other) {
        return other.m_success != this->m_success;
    }
    inline T expect(const char* errorMsg) {
        if (m_success == Success::Err) throw errorMsg;
        else return m_value.ok;
    }
    inline bool is_ok() {
        return m_success == Success::Ok;
    }
    inline bool is_err() {
        return m_success == Success::Err;
    }
    inline const T* ok() {
        if (is_ok()) return m_value.ok;
        else return nullptr;
    }
    inline const T* err() {
        if (is_err()) return m_value.err;
        else return nullptr;
    }

    // Other methods from https://doc.rust-lang.org/std/result/enum.Result.html

    private:
    Success m_success;
    union _val_t { T ok; E err; } m_value;
}