Scopo dei sindacati in C e C ++

Ho usato i sindacati prima comodamente; oggi sono stato allarmato quando ho letto questo post e ho scoperto che questo codice

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

è in realtà un comportamento indefinito Vale a dire leggere da un membro del sindacato diverso da quello scritto di recente porta a un comportamento indefinito. Se questo non è l'uso previsto dei sindacati, che cos'è? Qualcuno può spiegarlo in modo elaborato?

Aggiornare:

Volevo chiarire alcune cose con il senno di poi.

• La risposta alla domanda non è la stessa per C e C ++; il mio io più giovane ignorante lo ha etichettato sia come C che C ++.
• Dopo aver passato in rassegna lo standard di C ++ 11, non ho potuto dire in modo definitivo che invoca / ispeziona un membro sindacale non attivo non definito / non specificato / definito dall'implementazione. Tutto quello che ho trovato è stato §9.5 / 1:

  Se un'unione di layout standard contiene diverse strutture di layout standard che condividono una sequenza iniziale comune e se un oggetto di questo tipo di unione di layout standard contiene una delle strutture di layout standard, è consentito ispezionare la sequenza iniziale comune di qualsiasi dei membri della struttura a layout standard. §9.2 / 19: Due strutture di layout standard condividono una sequenza iniziale comune se i membri corrispondenti hanno tipi compatibili con il layout e nessuno dei due membri è un campo di bit o entrambi sono campi di bit con la stessa larghezza per una sequenza di una o più iniziali membri.

• Mentre sei in C, ( C99 TC3 - DR 283 in poi) è legale farlo ( grazie a Pascal Cuoq per averlo menzionato ). Tuttavia, tentare di farlo può comunque portare a comportamenti indefiniti , se il valore letto risulta non valido (la cosiddetta "rappresentazione trap") per il tipo che viene letto. Altrimenti, il valore letto è definito dall'implementazione.

• C89 / 90 lo ha definito sotto un comportamento non specificato (Allegato J) e il libro di K&R afferma che la sua implementazione è stata definita. Citazione da K&R:

  Questo è lo scopo di un'unione - una singola variabile che può legittimamente contenere uno di diversi tipi. [...] purché l'uso sia coerente: il tipo recuperato deve essere il tipo memorizzato più di recente. È responsabilità del programmatore tenere traccia di quale tipo è attualmente memorizzato in un sindacato; i risultati dipendono dall'implementazione se qualcosa viene archiviato come un tipo ed estratto come un altro.

• Estratto dal TC ++ PL di Stroustrup (il mio accento è mio)

  L'uso dei sindacati può essere essenziale per la compatibilità dei dati [...] talvolta utilizzati in modo improprio per la "conversione del tipo ".

Soprattutto, questa domanda (il cui titolo rimane invariato dalla mia domanda) è stata posta con l'intenzione di comprendere lo scopo dei sindacati E non su ciò che lo standard consente Ad es. L'uso dell'ereditarietà per il riutilizzo del codice è, ovviamente, consentito dallo standard C ++, ma non era lo scopo o l'intenzione originale di introdurre l'ereditarietà come funzionalità del linguaggio C ++ . Questo è il motivo per cui la risposta di Andrey continua a rimanere quella accettata.

Lo scopo dei sindacati è piuttosto ovvio, ma per qualche ragione la gente lo manca abbastanza spesso.

Lo scopo dell'unione è quello di risparmiare memoria utilizzando la stessa area di memoria per archiviare oggetti diversi in momenti diversi. Questo è tutto.

È come una stanza in un hotel. Diverse persone vivono in esso per periodi di tempo non sovrapposti. Queste persone non si incontrano mai e generalmente non sanno nulla l'una dell'altra. Gestendo correttamente la condivisione del tempo delle stanze (ovvero assicurandosi che persone diverse non vengano assegnate contemporaneamente a una stanza), un hotel relativamente piccolo può fornire alloggi a un numero relativamente elevato di persone, che è ciò che gli hotel sono per.

Questo è esattamente ciò che fa l'unione. Se sai che diversi oggetti nel tuo programma contengono valori con durata dei valori non sovrapponibili, puoi "unire" questi oggetti in un'unione e quindi risparmiare memoria. Proprio come una camera d'albergo ha al massimo un inquilino "attivo" in ogni momento del tempo, un sindacato ha al massimo un membro "attivo" in ogni momento del programma. È possibile leggere solo il membro "attivo". Scrivendo in un altro membro si passa lo stato "attivo" a quell'altro membro.

Per qualche ragione, questo scopo originale del sindacato è stato "ignorato" con qualcosa di completamente diverso: scrivere un membro di un sindacato e poi ispezionarlo attraverso un altro membro. Questo tipo di reinterpretazione della memoria (alias "type punning") non è un uso valido dei sindacati. Generalmente porta a comportamenti indefiniti che viene descritto come producendo comportamenti definiti dall'implementazione in C89 / 90.

EDIT: L' uso dei sindacati ai fini della punzonatura di tipo (cioè scrivere un membro e poi leggerne un altro) è stata data una definizione più dettagliata in una delle rettifiche tecniche allo standard C99 (vedi DR # 257 e DR # 283 ). Tuttavia, tieni presente che formalmente questo non ti protegge dall'incontrare un comportamento indefinito tentando di leggere una rappresentazione trappola.

È possibile utilizzare i sindacati per creare strutture come la seguente, che contiene un campo che ci dice quale componente dell'unione viene effettivamente utilizzato:

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

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

Il comportamento non è definito dal punto di vista linguistico. Considera che piattaforme diverse possono avere vincoli diversi nell'allineamento e nell'endianità della memoria. Il codice in una macchina big endian contro una macchina little endian aggiornerà i valori nella struttura in modo diverso. La correzione del comportamento nella lingua richiederebbe a tutte le implementazioni di utilizzare lo stesso endianness (e vincoli di allineamento della memoria ...) limitandone l'uso.

Se stai usando C ++ (stai usando due tag) e ti interessa davvero la portabilità, allora puoi semplicemente usare la struttura e fornire un setter che prende uint32_te imposta i campi in modo appropriato attraverso le operazioni di maschera di bit. Lo stesso può essere fatto in C con una funzione.

Modifica : mi aspettavo che AProgrammer scrivesse una risposta per votare e chiudesse questa. Come hanno sottolineato alcuni commenti, l'endianità viene trattata in altre parti dello standard lasciando che ogni implementazione decida cosa fare e l'allineamento e il riempimento possono anche essere gestiti in modo diverso. Ora, le rigide regole di alias a cui AProgrammer si riferisce implicitamente sono un punto importante qui. Al compilatore è consentito fare ipotesi sulla modifica (o mancanza di modifica) delle variabili. Nel caso dell'unione, il compilatore potrebbe riordinare le istruzioni e spostare la lettura di ciascun componente di colore sulla scrittura nella variabile colore.

L' uso più comune di cui unionmi imbatto regolarmente è l' aliasing .

Considera quanto segue:

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

Cosa fa questo? Permette l'accesso pulito e ordinato dei Vector3f vec;membri di uno con uno dei due nomi:

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

o tramite accesso intero nell'array

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

In alcuni casi, l'accesso per nome è la cosa più chiara che puoi fare. In altri casi, specialmente quando l'asse viene scelto a livello di codice, la cosa più semplice da fare è accedere all'asse tramite indice numerico: 0 per x, 1 per ye 2 per z.

Come dici tu, questo è un comportamento strettamente indefinito, anche se "funzionerà" su molte piattaforme. La vera ragione per usare i sindacati è creare record di varianti.

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;

Naturalmente, hai anche bisogno di una sorta di discriminatore per dire cosa contiene effettivamente la variante. E nota che in C ++ i sindacati non sono molto utili perché possono contenere solo tipi di POD - effettivamente quelli senza costruttori e distruttori.

In C è stato un bel modo di implementare qualcosa come una variante.

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 tempi di poca memoria questa struttura utilizza meno memoria di una struttura che ha tutto il membro.

A proposito C fornisce

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

per accedere ai valori dei bit.

Sebbene questo sia un comportamento strettamente indefinito, in pratica funzionerà praticamente con qualsiasi compilatore. È un paradigma così ampiamente usato che qualsiasi compilatore che si rispetti dovrà fare "la cosa giusta" in casi come questo. È certamente da preferire al tipo di punzonatura, che potrebbe generare codice rotto con alcuni compilatori.

In C ++, Boost Variant implementa una versione sicura dell'unione, progettata per prevenire il più possibile comportamenti indefiniti.

Le sue prestazioni sono identiche al enum + unioncostrutto (allocato anche nello stack, ecc.) Ma utilizza un elenco di modelli di tipi anziché enum:)

Il comportamento potrebbe non essere definito, ma ciò significa che non esiste uno "standard". Tutti i compilatori decenti offrono #pragmas per controllare l'imballaggio e l'allineamento, ma possono avere impostazioni predefinite diverse. Le impostazioni predefinite cambieranno anche in base alle impostazioni di ottimizzazione utilizzate.

Inoltre, i sindacati non sono solo per risparmiare spazio. Possono aiutare i compilatori moderni con la punzonatura di tipo. Se reinterpret_cast<>tutto il compilatore non può fare ipotesi su quello che stai facendo. Potrebbe essere necessario eliminare ciò che sa sul tuo tipo e ricominciare (forzando una riscrittura in memoria, che è molto inefficiente in questi giorni rispetto alla velocità di clock della CPU).

Tecnicamente non è definito, ma in realtà la maggior parte (tutti?) I compilatori lo trattano esattamente come usando un reinterpret_castda un tipo all'altro, il cui risultato è l'implementazione definita. Non perderei sonno sul tuo codice attuale.

Per un altro esempio dell'uso effettivo dei sindacati, il framework CORBA serializza gli oggetti usando l'approccio sindacato con tag. Tutte le classi definite dall'utente sono membri di un'unione (enorme) e un identificatore intero indica al demarshaller come interpretare l'unione.

Altri hanno menzionato le differenze di architettura (little - big endian).

Ho letto il problema che, poiché la memoria per le variabili è condivisa, quindi scrivendo su una, le altre cambiano e, a seconda del loro tipo, il valore potrebbe essere privo di significato.

per esempio. union {float f; int i; } X;

Scrivere su xi non avrebbe senso se poi leggessi da xf - a meno che non fosse quello che intendevi per guardare il segno, l'esponente o le componenti della mantissa del galleggiante.

Penso che ci sia anche un problema di allineamento: se alcune variabili devono essere allineate a parole, potresti non ottenere il risultato atteso.

per esempio. unione {char c [4]; int i; } X;

Se, ipoteticamente, su una macchina un carattere dovesse essere allineato a parole, allora c [0] e c [1] condivideranno la memoria con i ma non c [2] e c [3].

Nel linguaggio C come documentato nel 1974, tutti i membri della struttura condividevano uno spazio dei nomi comune e il significato di "ptr-> member" era definito come l'aggiunta dello spostamento del membro a "ptr" e l'accesso all'indirizzo risultante usando il tipo di membro. Questo design ha permesso di utilizzare lo stesso ptr con nomi di membri presi da definizioni di strutture diverse ma con lo stesso offset; i programmatori hanno usato quell'abilità per una varietà di scopi.

Quando ai membri della struttura venivano assegnati i propri spazi dei nomi, divenne impossibile dichiarare due membri della struttura con lo stesso spostamento. L'aggiunta di sindacati alla lingua ha reso possibile ottenere la stessa semantica che era stata disponibile nelle versioni precedenti della lingua (sebbene l'incapacità di avere nomi esportati in un contesto accluso potrebbe aver ancora reso necessario l'uso di un comando trova / sostituisci per sostituire il membro> in foo-> type1.member). Ciò che era importante non era tanto che le persone che avevano aggiunto i sindacati avessero in mente un particolare utilizzo del target, ma piuttosto che fornivano un mezzo con cui i programmatori che avevano fatto affidamento sulla semantica precedente, per qualunque scopo , avrebbero potuto comunque essere in grado di raggiungere il stessa semantica anche se dovevano usare una sintassi diversa per farlo.

È possibile utilizzare un sindacato per due motivi principali:

1. Un modo pratico per accedere agli stessi dati in diversi modi, come nel tuo esempio
2. Un modo per risparmiare spazio quando ci sono diversi membri di dati di cui solo uno può essere "attivo"

1 È davvero più un hack in stile C per abbreviare la scrittura del codice sulla base della conoscenza dell'architettura di memoria del sistema di destinazione. Come già detto, di solito puoi cavartela se in realtà non scegli come target molte piattaforme diverse. Credo che alcuni compilatori potrebbero permetterti di usare anche le direttive sull'imballaggio (so che lo fanno sulle strutture)?

Un buon esempio di 2. può essere trovato nel tipo VARIANT ampiamente utilizzato in COM.

Come altri hanno già detto, i sindacati combinati con le enumerazioni e inseriti in strutture possono essere utilizzati per implementare i sindacati con tag. Un uso pratico è implementare Rust Result<T, E>, che è originariamente implementato usando un puro enum(Rust può contenere dati aggiuntivi nelle varianti di enumerazione). Ecco un esempio in 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;
}