Zweck der Gewerkschaften in C und C ++

Ich habe Gewerkschaften früher bequem benutzt; Heute war ich alarmiert, als ich diesen Beitrag las und erfuhr, dass dieser Code

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

ist tatsächlich undefiniertes Verhalten, dh das Lesen von einem anderen Gewerkschaftsmitglied als dem, an das kürzlich geschrieben wurde, führt zu undefiniertem Verhalten. Wenn dies nicht die beabsichtigte Verwendung von Gewerkschaften ist, was ist das? Kann jemand es bitte ausführlich erklären?

Aktualisieren:

Ich wollte im Nachhinein ein paar Dinge klären.

• Die Antwort auf die Frage ist für C und C ++ nicht dieselbe. Mein ignorantes jüngeres Ich hat es sowohl als C als auch als C ++ markiert.
• Nachdem ich den Standard von C ++ 11 durchgesehen hatte, konnte ich nicht abschließend sagen, dass der Zugriff auf / die Inspektion eines nicht aktiven Gewerkschaftsmitglieds undefiniert / nicht spezifiziert / implementierungsdefiniert ist. Alles was ich finden konnte war §9.5 / 1:

  Wenn eine Standard-Layout-Union mehrere Standard-Layout-Strukturen enthält, die eine gemeinsame Anfangssequenz haben, und wenn ein Objekt dieses Standard-Layout-Union-Typs eine der Standard-Layout-Strukturen enthält, kann die gemeinsame Anfangssequenz einer beliebigen Struktur überprüft werden von Standard-Layout-Strukturelementen. §9.2 / 19: Zwei Standardlayoutstrukturen teilen eine gemeinsame Anfangssequenz, wenn entsprechende Elemente layoutkompatible Typen haben und entweder kein Element ein Bitfeld ist oder beide Bitfelder mit derselben Breite für eine Sequenz von einem oder mehreren Anfangsbuchstaben sind Mitglieder.

• In C (ab C99 TC3 - DR 283 ) ist dies legal ( danke an Pascal Cuoq , der dies angesprochen hat). Der Versuch, dies zu tun , kann jedoch immer noch zu undefiniertem Verhalten führen , wenn der gelesene Wert für den Typ, den er durchliest, ungültig ist (sogenannte "Trap-Darstellung"). Andernfalls wird der gelesene Wert implementierungsdefiniert.

• C89 / 90 hat dies unter nicht spezifiziertem Verhalten (Anhang J) herausgestellt, und das Buch von K & R besagt, dass die Implementierung definiert ist. Zitat von K & R:

  Dies ist der Zweck einer Union - eine einzelne Variable, die einen von mehreren Typen rechtmäßig enthalten kann. [...] solange die Verwendung konsistent ist: Der abgerufene Typ muss der zuletzt gespeicherte Typ sein. Es liegt in der Verantwortung des Programmierers, zu verfolgen, welcher Typ derzeit in einer Union gespeichert ist. Die Ergebnisse sind implementierungsabhängig, wenn etwas als ein Typ gespeichert und als ein anderer extrahiert wird.

• Auszug aus Stroustrups TC ++ PL (Schwerpunkt Mine)

  Die Verwendung von Gewerkschaften kann für die Kompatibilität von Daten von wesentlicher Bedeutung sein, [...] die manchmal für die "Typkonvertierung " missbraucht werden .

Vor allem diese Frage (deren Titel seit meiner Anfrage unverändert geblieben ist) wurde mit der Absicht gestellt, den Zweck von Gewerkschaften zu verstehen UND nicht darüber, was der Standard erlaubt. ZB Die Verwendung der Vererbung für die Wiederverwendung von Code ist natürlich nach dem C ++ - Standard zulässig, aber Es war nicht der Zweck oder die ursprüngliche Absicht, Vererbung als C ++ - Sprachfunktion einzuführen . Dies ist der Grund, warum Andreys Antwort weiterhin die akzeptierte bleibt.

Der Zweck der Gewerkschaften liegt auf der Hand, aber aus irgendeinem Grund vermissen die Leute ihn ziemlich oft.

Der Zweck der Vereinigung besteht darin, Speicher zu sparen, indem derselbe Speicherbereich zum Speichern verschiedener Objekte zu unterschiedlichen Zeiten verwendet wird. Das ist es.

Es ist wie ein Zimmer in einem Hotel. Verschiedene Menschen leben für nicht überlappende Zeiträume darin. Diese Leute treffen sich nie und wissen im Allgemeinen nichts voneinander. Durch die ordnungsgemäße Verwaltung der zeitlichen Aufteilung der Zimmer (dh durch Sicherstellen, dass nicht gleichzeitig verschiedene Personen einem Zimmer zugewiesen werden) kann ein relativ kleines Hotel einer relativ großen Anzahl von Personen Unterkünfte bieten, was auch Hotels sind sind für.

Genau das macht Union. Wenn Sie wissen, dass mehrere Objekte in Ihrem Programm Werte mit nicht überlappenden Wertlebensdauern enthalten, können Sie diese Objekte zu einer Vereinigung "zusammenführen" und so Speicher sparen. So wie ein Hotelzimmer zu jedem Zeitpunkt höchstens einen "aktiven" Mieter hat, hat eine Gewerkschaft zu jedem Zeitpunkt der Programmzeit höchstens ein "aktives" Mitglied. Nur das "aktive" Mitglied kann gelesen werden. Indem Sie in ein anderes Mitglied schreiben, wechseln Sie den Status "aktiv" zu diesem anderen Mitglied.

Aus irgendeinem Grund wurde dieser ursprüngliche Zweck der Gewerkschaft durch etwas völlig anderes "außer Kraft gesetzt": ein Mitglied einer Gewerkschaft zu schreiben und es dann durch ein anderes Mitglied zu inspizieren. Diese Art der Neuinterpretation des Gedächtnisses (auch bekannt als "Typ Punning") ist keine gültige Verwendung von Gewerkschaften. Es führt im Allgemeinen dazu, dass undefiniertes Verhalten in C89 / 90 als implementierungsdefiniertes Verhalten beschrieben wird.

BEARBEITEN: Die Verwendung von Gewerkschaften zum Zwecke der Typisierung (dh Schreiben eines Mitglieds und anschließendes Lesen eines anderen) wurde in einer der technischen Berichtigungen zum C99-Standard ausführlicher definiert (siehe DR # 257 und DR # 283 ). Beachten Sie jedoch, dass dies Sie formal nicht vor undefiniertem Verhalten schützt, indem Sie versuchen, eine Trap-Darstellung zu lesen.

Sie können Gewerkschaften verwenden, um Strukturen wie die folgenden zu erstellen, die ein Feld enthalten, das angibt, welche Komponente der Vereinigung tatsächlich verwendet wird:

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

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

Das Verhalten ist aus sprachlicher Sicht undefiniert. Bedenken Sie, dass unterschiedliche Plattformen unterschiedliche Einschränkungen hinsichtlich Speicherausrichtung und Endianness aufweisen können. Der Code in einer Big-Endian-Maschine im Vergleich zu einer Little-Endian-Maschine aktualisiert die Werte in der Struktur unterschiedlich. Um das Verhalten in der Sprache zu korrigieren, müssten alle Implementierungen dieselbe Endianness (und Speicherausrichtungsbeschränkungen ...) verwenden, was die Verwendung einschränkt.

Wenn Sie C ++ verwenden (Sie verwenden zwei Tags) und die Portabilität wirklich wichtig ist, können Sie einfach die Struktur verwenden und einen Setter bereitstellen, der uint32_tdie Felder durch Bitmaskenoperationen entsprechend festlegt. Das gleiche kann in C mit einer Funktion gemacht werden.

Bearbeiten : Ich hatte erwartet, dass AProgrammer eine Antwort aufschreibt, um abzustimmen und diese zu schließen. Wie einige Kommentare hervorgehoben haben, wird Endianness in anderen Teilen des Standards behandelt, indem jede Implementierung entscheiden lässt, was zu tun ist, und Ausrichtung und Polsterung können auch unterschiedlich gehandhabt werden. Nun sind die strengen Aliasing-Regeln, auf die sich AProgrammer implizit bezieht, hier ein wichtiger Punkt. Der Compiler darf Annahmen über die Änderung (oder das Fehlen einer Änderung) von Variablen treffen. Im Fall der Vereinigung könnte der Compiler Anweisungen neu anordnen und den Lesevorgang jeder Farbkomponente über den Schreibvorgang in die Farbvariable verschieben.

Die häufigste Verwendung, auf die unionich regelmäßig stoße, ist Aliasing .

Folgendes berücksichtigen:

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

Was macht das? Es ermöglicht einen sauberen und übersichtlichen Zugriff auf Vector3f vec;die Mitglieder eines der beiden Namen:

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

oder durch ganzzahligen Zugriff auf das Array

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

In einigen Fällen ist der Zugriff über den Namen das klarste, was Sie tun können. In anderen Fällen, insbesondere wenn die Achse programmgesteuert ausgewählt wird, ist es einfacher, auf die Achse über den numerischen Index zuzugreifen - 0 für x, 1 für y und 2 für z.

Wie Sie sagen, ist dies ein streng undefiniertes Verhalten, obwohl es auf vielen Plattformen "funktioniert". Der eigentliche Grund für die Verwendung von Gewerkschaften besteht darin, Variantendatensätze zu erstellen.

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;

Natürlich brauchen Sie auch eine Art Diskriminator, um zu sagen, was die Variante tatsächlich enthält. Beachten Sie, dass Gewerkschaften in C ++ nicht viel Verwendung finden, da sie nur POD-Typen enthalten können - effektiv solche ohne Konstruktoren und Destruktoren.

In C war es eine gute Möglichkeit, so etwas wie eine Variante zu implementieren.

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;

In Zeiten mit wenig Speicher benötigt diese Struktur weniger Speicher als eine Struktur mit allen Mitgliedern.

Übrigens bietet C.

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

um auf Bitwerte zuzugreifen.

Obwohl dies ein streng undefiniertes Verhalten ist, funktioniert es in der Praxis mit so ziemlich jedem Compiler. Es ist ein so weit verbreitetes Paradigma, dass jeder Compiler mit Selbstachtung in solchen Fällen "das Richtige" tun muss. Es ist sicherlich dem Typ-Punning vorzuziehen, das bei einigen Compilern möglicherweise fehlerhaften Code erzeugt.

In C ++ implementiert Boost Variant eine sichere Version der Union, um undefiniertes Verhalten so weit wie möglich zu verhindern.

Seine Leistung ist identisch mit dem enum + unionKonstrukt (Stapel auch zugewiesen usw.), aber es verwendet eine Vorlagenliste von Typen anstelle der enum:)

Das Verhalten mag undefiniert sein, aber das bedeutet nur, dass es keinen "Standard" gibt. Alle anständigen Compiler bieten #pragmas an, um das Packen und Ausrichten zu steuern, können jedoch unterschiedliche Standardeinstellungen haben. Die Standardeinstellungen ändern sich auch in Abhängigkeit von den verwendeten Optimierungseinstellungen.

Gewerkschaften sind nicht nur platzsparend. Sie können modernen Compilern beim Typ Punning helfen. Wenn Sie reinterpret_cast<>alles haben, kann der Compiler keine Annahmen darüber treffen, was Sie tun. Möglicherweise muss es das, was es über Ihren Typ weiß, wegwerfen und erneut starten (ein Zurückschreiben in den Speicher erzwingen, was heutzutage im Vergleich zur CPU-Taktrate sehr ineffizient ist).

Technisch gesehen ist es undefiniert, aber in Wirklichkeit behandeln die meisten (alle?) Compiler es genauso wie die Verwendung eines reinterpret_castvon einem Typ zum anderen, dessen Ergebnis die Implementierung definiert ist. Ich würde nicht den Schlaf über Ihren aktuellen Code verlieren.

Für ein weiteres Beispiel für die tatsächliche Verwendung von Gewerkschaften serialisiert das CORBA-Framework Objekte mithilfe des Ansatzes der markierten Vereinigung. Alle benutzerdefinierten Klassen sind Mitglieder einer (großen) Union, und eine Ganzzahlkennung teilt dem Demarshaller mit, wie die Union zu interpretieren ist.

Andere haben die Architekturunterschiede erwähnt (Little - Big Endian).

Ich habe das Problem gelesen, dass sich die anderen ändern, da der Speicher für die Variablen gemeinsam genutzt wird. Wenn Sie in eine schreiben, ändern sich die anderen und je nach Typ kann der Wert bedeutungslos sein.

z.B. Vereinigung {float f; int i; } x;

Das Schreiben in xi wäre bedeutungslos, wenn Sie dann aus xf lesen - es sei denn, Sie haben dies beabsichtigt, um die Vorzeichen-, Exponenten- oder Mantissenkomponenten des Floats zu betrachten.

Ich denke, es gibt auch ein Problem mit der Ausrichtung: Wenn einige Variablen wortausgerichtet sein müssen, erhalten Sie möglicherweise nicht das erwartete Ergebnis.

z.B. Vereinigung {char c [4]; int i; } x;

Wenn hypothetisch auf einem Computer ein Zeichen wortausgerichtet werden müsste, würden c [0] und c [1] den Speicher mit i teilen, nicht jedoch c [2] und c [3].

In der C-Sprache, wie sie 1974 dokumentiert wurde, hatten alle Strukturmitglieder einen gemeinsamen Namespace, und die Bedeutung von "ptr-> member" wurde definiert als Hinzufügen der Verschiebung des Mitglieds zu "ptr" und Zugreifen auf die resultierende Adresse unter Verwendung des Mitgliedstyps. Dieses Design ermöglichte die Verwendung desselben ptr mit Mitgliedsnamen aus verschiedenen Strukturdefinitionen, jedoch mit demselben Versatz. Programmierer nutzten diese Fähigkeit für eine Vielzahl von Zwecken.

Wenn Strukturelementen ihre eigenen Namespaces zugewiesen wurden, war es unmöglich, zwei Strukturelemente mit derselben Verschiebung zu deklarieren. Das Hinzufügen von Gewerkschaften zur Sprache ermöglichte es, dieselbe Semantik zu erreichen, die in früheren Versionen der Sprache verfügbar war (obwohl die Unfähigkeit, Namen in einen umschließenden Kontext exportieren zu lassen, möglicherweise immer noch die Verwendung eines Find / Replace zum Ersetzen von foo-> member erforderlich gemacht hat in foo-> type1.member). Was wichtig war, war nicht so sehr, dass die Leute, die Gewerkschaften hinzugefügt haben, eine bestimmte Zielverwendung im Auge haben, sondern dass sie ein Mittel darstellen, mit dem Programmierer, die sich für welchen Zweck auch immer auf die frühere Semantik verlassen hatten, in der Lage sein sollten, dies zu erreichen gleiche Semantik, auch wenn sie dafür eine andere Syntax verwenden mussten.

Sie können verwenden aa Vereinigung aus zwei Gründen:

1. Eine praktische Möglichkeit, auf unterschiedliche Weise auf dieselben Daten zuzugreifen, wie in Ihrem Beispiel
2. Eine Möglichkeit, Platz zu sparen, wenn es verschiedene Datenelemente gibt, von denen nur eines jemals "aktiv" sein kann.

1 Ist wirklich eher ein C-Hack, um Code zu verkürzen, wenn Sie wissen, wie die Speicherarchitektur des Zielsystems funktioniert. Wie bereits gesagt, können Sie normalerweise damit durchkommen, wenn Sie nicht auf viele verschiedene Plattformen abzielen. Ich glaube, einige Compiler lassen Sie möglicherweise auch Packanweisungen verwenden (ich weiß, dass sie dies für Strukturen tun).

Ein gutes Beispiel für 2. ist der Typ VARIANT, der in COM häufig verwendet wird.

Wie bereits erwähnt, können Gewerkschaften in Kombination mit Aufzählungen und in Strukturen eingeschlossen werden, um markierte Gewerkschaften zu implementieren. Eine praktische Anwendung ist die Implementierung von Rusts Result<T, E>, die ursprünglich mit einem reinen implementiert wurden enum(Rust kann zusätzliche Daten in Aufzählungsvarianten enthalten). Hier ist ein C ++ - Beispiel:

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;
}