¿Por qué necesitamos C Unions?

¿Cuándo deben usarse los sindicatos? ¿Por qué los necesitamos?

Las uniones a menudo se usan para convertir entre las representaciones binarias de enteros y flotantes:

union
{
  int i;
  float f;
} u;

// Convert floating-point bits to integer:
u.f = 3.14159f;
printf("As integer: %08x\n", u.i);

Aunque este es un comportamiento técnicamente indefinido de acuerdo con el estándar C (se supone que solo debe leer el campo que se escribió más recientemente), actuará de manera bien definida en prácticamente cualquier compilador.

Las uniones también se usan a veces para implementar pseudopolimorfismos en C, al dar a la estructura una etiqueta que indica qué tipo de objeto contiene y luego unir los tipos posibles:

enum Type { INTS, FLOATS, DOUBLE };
struct S
{
  Type s_type;
  union
  {
    int s_ints[2];
    float s_floats[2];
    double s_double;
  };
};

void do_something(struct S *s)
{
  switch(s->s_type)
  {
    case INTS:  // do something with s->s_ints
      break;

    case FLOATS:  // do something with s->s_floats
      break;

    case DOUBLE:  // do something with s->s_double
      break;
  }
}

Esto permite que el tamaño struct Ssea ​​de solo 12 bytes, en lugar de 28.

Los sindicatos son particularmente útiles en la programación integrada o en situaciones en las que se necesita acceso directo al hardware / memoria. Aquí hay un ejemplo trivial:

typedef union
{
    struct {
        unsigned char byte1;
        unsigned char byte2;
        unsigned char byte3;
        unsigned char byte4;
    } bytes;
    unsigned int dword;
} HW_Register;
HW_Register reg;

Luego puede acceder al registro de la siguiente manera:

reg.dword = 0x12345678;
reg.bytes.byte3 = 4;

Endianness (orden de bytes) y la arquitectura del procesador son, por supuesto, importantes.

Otra característica útil es el modificador de bits:

typedef union
{
    struct {
        unsigned char b1:1;
        unsigned char b2:1;
        unsigned char b3:1;
        unsigned char b4:1;
        unsigned char reserved:4;
    } bits;
    unsigned char byte;
} HW_RegisterB;
HW_RegisterB reg;

Con este código puede acceder directamente a un solo bit en la dirección de registro / memoria:

x = reg.bits.b2;

La programación del sistema de bajo nivel es un ejemplo razonable.

IIRC, he usado sindicatos para desglosar registros de hardware en los bits componentes. Entonces, puede acceder a un registro de 8 bits (como estaba, el día que hice esto ;-) en los bits de componentes.

(Olvidé la sintaxis exacta pero ...) Esta estructura permitiría acceder a un registro de control como control_byte o mediante los bits individuales. Sería importante asegurarse de que los bits se correspondan con los bits de registro correctos para una endianidad dada.

typedef union {
    unsigned char control_byte;
    struct {
        unsigned int nibble  : 4;
        unsigned int nmi     : 1;
        unsigned int enabled : 1;
        unsigned int fired   : 1;
        unsigned int control : 1;
    };
} ControlRegister;

Lo he visto en un par de bibliotecas como un reemplazo para la herencia orientada a objetos.

P.ej

        Connection
     /       |       \
  Network   USB     VirtualConnection

Si desea que la "clase" de Connection sea una de las anteriores, puede escribir algo como:

struct Connection
{
    int type;
    union
    {
        struct Network network;
        struct USB usb;
        struct Virtual virtual;
    }
};

Ejemplo de uso en libinfinity: http://git.0x539.de/?p=infinote.git;a=blob;f=libinfinity/common/inf-session.c;h=3e887f0d63bd754c6b5ec232948027cbbf4d61fc;hb=HEAD#l74

Los sindicatos permiten que los miembros de datos que se excluyen mutuamente compartan la misma memoria. Esto es bastante importante cuando la memoria es más escasa, como en los sistemas integrados.

En el siguiente ejemplo:

union {
   int a;
   int b;
   int c;
} myUnion;

Esta unión ocupará el espacio de un único int, en lugar de 3 valores int separados. Si el usuario establece el valor de a , y luego establece el valor de b , sobrescribirá el valor de a ya que ambos comparten la misma ubicación de memoria.

Muchos usos. Solo hazlo grep union /usr/include/*o en directorios similares. La mayoría de los casos unionse envuelve en un structmiembro de la estructura y uno le dice a qué elemento de la unión acceder. Por ejemplo, pago man elfpara implementaciones de la vida real.

Este es el principio básico:

struct _mydata {
    int which_one;
    union _data {
            int a;
            float b;
            char c;
    } foo;
} bar;

switch (bar.which_one)
{
   case INTEGER  :  /* access bar.foo.a;*/ break;
   case FLOATING :  /* access bar.foo.b;*/ break;
   case CHARACTER:  /* access bar.foo.c;*/ break;
}

Aquí hay un ejemplo de una unión de mi propia base de código (de memoria y parafraseada, por lo que puede no ser exacta). Fue utilizado para almacenar elementos del lenguaje en un intérprete que construí. Por ejemplo, el siguiente código:

set a to b times 7.

consta de los siguientes elementos del lenguaje:

• símbolo [conjunto]
• variable [a]
• símbolo [a]
• variable [b]
• símbolo [veces]
• constante [7]
• símbolo[.]

Los elementos del lenguaje se definieron como #definevalores ' ' por lo tanto:

#define ELEM_SYM_SET        0
#define ELEM_SYM_TO         1
#define ELEM_SYM_TIMES      2
#define ELEM_SYM_FULLSTOP   3
#define ELEM_VARIABLE     100
#define ELEM_CONSTANT     101

y se utilizó la siguiente estructura para almacenar cada elemento:

typedef struct {
    int typ;
    union {
        char *str;
        int   val;
    }
} tElem;

entonces el tamaño de cada elemento era el tamaño de la unión máxima (4 bytes para el tipo y 4 bytes para la unión, aunque esos son valores típicos, el valor real tamaños dependen de la implementación).

Para crear un elemento "conjunto", usaría:

tElem e;
e.typ = ELEM_SYM_SET;

Para crear un elemento "variable [b]", usaría:

tElem e;
e.typ = ELEM_VARIABLE;
e.str = strdup ("b");   // make sure you free this later

Para crear un elemento "constante [7]", usaría:

tElem e;
e.typ = ELEM_CONSTANT;
e.val = 7;

y podría expandirlo fácilmente para incluir flotantes ( float flt) o racionales ( struct ratnl {int num; int denom;}) y otros tipos.

La premisa básica es que stry valno son contiguos en la memoria, en realidad se superponen, por lo que es una forma de obtener una vista diferente en el mismo bloque de memoria, ilustrado aquí, donde la estructura se basa en la ubicación de la memoria 0x1010y los enteros y punteros son ambos 4 bytes:

       +-----------+
0x1010 |           |
0x1011 |    typ    |
0x1012 |           |
0x1013 |           |
       +-----+-----+
0x1014 |     |     |
0x1015 | str | val |
0x1016 |     |     |
0x1017 |     |     |
       +-----+-----+

Si solo estuviera en una estructura, se vería así:

       +-------+
0x1010 |       |
0x1011 |  typ  |
0x1012 |       |
0x1013 |       |
       +-------+
0x1014 |       |
0x1015 |  str  |
0x1016 |       |
0x1017 |       |
       +-------+
0x1018 |       |
0x1019 |  val  |
0x101A |       |
0x101B |       |
       +-------+

Yo diría que hace que sea más fácil reutilizar la memoria que podría usarse de diferentes maneras, es decir, ahorrar memoria. Por ejemplo, le gustaría hacer una estructura "variante" que pueda guardar una cadena corta y un número:

struct variant {
    int type;
    double number;
    char *string;
};

En un sistema de 32 bits, esto daría como resultado al menos 96 bits o 12 bytes para cada instancia de variant.

Con una unión, puede reducir el tamaño a 64 bits u 8 bytes:

struct variant {
    int type;
    union {
        double number;
        char *string;
    } value;
};

Puede ahorrar aún más si desea agregar más tipos de variables diferentes, etc. Podría ser cierto, que puede hacer cosas similares lanzando un puntero vacío, pero la unión lo hace mucho más accesible, así como escribir seguro. Tales ahorros no suenan masivos, pero está ahorrando un tercio de la memoria utilizada para todas las instancias de esta estructura.

Es difícil pensar en una ocasión específica en la que necesite este tipo de estructura flexible, tal vez en un protocolo de mensaje en el que enviaría mensajes de diferentes tamaños, pero incluso entonces probablemente haya alternativas mejores y más amigables para el programador.

Los sindicatos son un poco como los tipos de variantes en otros idiomas: solo pueden contener una cosa a la vez, pero esa cosa podría ser un int, un flotante, etc. dependiendo de cómo lo declare.

Por ejemplo:

typedef union MyUnion MYUNION;
union MyUnion
{
   int MyInt;
   float MyFloat;
};

MyUnion solo contendrá un int O un flotante, dependiendo de lo que haya configurado más recientemente . Entonces haciendo esto:

MYUNION u;
u.MyInt = 10;

u ahora tiene un int igual a 10;

u.MyFloat = 1.0;

Ahora tiene un flotador igual a 1.0. Ya no tiene un int. Obviamente ahora si intenta hacer printf ("MyInt =% d", u.MyInt); entonces probablemente obtendrá un error, aunque no estoy seguro del comportamiento específico.

El tamaño de la unión está dictado por el tamaño de su campo más grande, en este caso el flotador.

Las uniones se utilizan cuando desea modelar estructuras definidas por hardware, dispositivos o protocolos de red, o cuando está creando una gran cantidad de objetos y desea ahorrar espacio. Sin embargo, realmente no los necesita el 95% del tiempo, siga con el código fácil de depurar.

Muchas de estas respuestas se refieren a la transmisión de un tipo a otro. Aprovecho al máximo las uniones con los mismos tipos, solo un poco más (es decir, al analizar un flujo de datos en serie). Permiten que el análisis / construcción de un paquete enmarcado sea ​​trivial.

typedef union
{
    UINT8 buffer[PACKET_SIZE]; // Where the packet size is large enough for
                               // the entire set of fields (including the payload)

    struct
    {
        UINT8 size;
        UINT8 cmd;
        UINT8 payload[PAYLOAD_SIZE];
        UINT8 crc;
    } fields;

}PACKET_T;

// This should be called every time a new byte of data is ready 
// and point to the packet's buffer:
// packet_builder(packet.buffer, new_data);

void packet_builder(UINT8* buffer, UINT8 data)
{
    static UINT8 received_bytes = 0;

    // All range checking etc removed for brevity

    buffer[received_bytes] = data;
    received_bytes++;

    // Using the struc only way adds lots of logic that relates "byte 0" to size
    // "byte 1" to cmd, etc...
}

void packet_handler(PACKET_T* packet)
{
    // Process the fields in a readable manner
    if(packet->fields.size > TOO_BIG)
    {
        // handle error...
    }

    if(packet->fields.cmd == CMD_X)
    {
        // do stuff..
    }
}

Editar El comentario sobre endianness y estructura de relleno son válidos y grandes preocupaciones. He usado este cuerpo de código casi por completo en software embebido, la mayoría de los cuales tenía control de ambos extremos de la tubería.

Los sindicatos son geniales. Un uso inteligente de los sindicatos que he visto es usarlos al definir un evento. Por ejemplo, puede decidir que un evento es de 32 bits.

Ahora, dentro de esos 32 bits, es posible que desee designar los primeros 8 bits como un identificador del remitente del evento ... A veces trata el evento como un todo, a veces lo disecciona y compara sus componentes. los sindicatos te dan la flexibilidad para hacer ambas cosas.

Evento sindical
{
  unsigned long eventCode;
  unsigned char eventParts [4];
};

¿Qué pasa con VARIANTeso que se usa en las interfaces COM? Tiene dos campos: "tipo" y una unión que contiene un valor real que se trata según el campo "tipo".

En la escuela, usaba sindicatos como este:

typedef union
{
  unsigned char color[4];
  int       new_color;
}       u_color;

Lo usé para manejar los colores más fácilmente, en lugar de usar operadores >> y <<, solo tuve que pasar por el índice diferente de mi matriz de caracteres.

Usé union cuando estaba codificando para dispositivos integrados. Tengo C int que tiene 16 bits de largo. Y necesito recuperar los 8 bits más altos y los 8 bits más bajos cuando necesito leer / almacenar en EEPROM. Así que usé de esta manera:

union data {
    int data;
    struct {
        unsigned char higher;
        unsigned char lower;
    } parts;
};

No requiere cambios, por lo que el código es más fácil de leer.

Por otro lado, vi un código antiguo de C ++ stl que usaba union para stl allocator. Si está interesado, puede leer el código fuente sgi stl . Aquí hay una parte:

union _Obj {
    union _Obj* _M_free_list_link;
    char _M_client_data[1];    /* The client sees this.        */
};

• Un archivo que contiene diferentes tipos de registros.
• Una interfaz de red que contiene diferentes tipos de solicitud.

Eche un vistazo a esto: manejo del comando de almacenamiento intermedio X.25

Uno de los muchos comandos X.25 posibles se recibe en un búfer y se maneja en su lugar utilizando una UNIÓN de todas las estructuras posibles.

En las primeras versiones de C, todas las declaraciones de estructura compartirían un conjunto común de campos. Dado:

struct x {int x_mode; int q; float x_f};
struct y {int y_mode; int q; int y_l};
struct z {int z_mode; char name[20];};

un compilador esencialmente produciría una tabla de tamaños de estructuras (y posiblemente alineaciones), y una tabla separada de nombres, tipos y compensaciones de miembros de estructuras. El compilador no realizó un seguimiento de qué miembros pertenecían a qué estructuras, y permitiría que dos estructuras tengan un miembro con el mismo nombre solo si el tipo y el desplazamiento coinciden (como con el miembro qde struct xy struct y). Si p fuera un puntero a cualquier tipo de estructura, p-> q agregaría el desplazamiento de "q" al puntero p y buscaría un "int" de la dirección resultante.

Dada la semántica anterior, era posible escribir una función que pudiera realizar algunas operaciones útiles en múltiples tipos de estructura de manera intercambiable, siempre que todos los campos utilizados por la función se alinearan con campos útiles dentro de las estructuras en cuestión. Esta era una característica útil, y cambiar C para validar los miembros utilizados para el acceso a la estructura contra los tipos de estructuras en cuestión habría significado perderlo en ausencia de un medio para tener una estructura que pueda contener múltiples campos con nombre en la misma dirección. Agregar tipos de "unión" a C ayudó a llenar ese vacío (aunque no, en mi humilde opinión, como debería haber sido).

Una parte esencial de la capacidad de los sindicatos para llenar ese vacío fue el hecho de que un puntero a un miembro de la unión podría convertirse en un puntero a cualquier unión que contenga ese miembro, y un puntero a cualquier unión podría convertirse en un puntero a cualquier miembro. Si bien el Estándar C89 no dijo expresamente que lanzar un T*directamente a un U*era equivalente a lanzarlo a un puntero a cualquier tipo de unión que contenga ambos Ty U, y luego lanzarlo a U*, ningún comportamiento definido de la última secuencia de lanzamiento se vería afectado por el tipo de unión utilizado, y el Estándar no especificó ninguna semántica contraria para un lanzamiento directo de Ta U. Además, en los casos en que una función recibió un puntero de origen desconocido, el comportamiento de escribir un objeto a travésT* conversión deT*a a U*, y luego leer el objeto a través U*sería equivalente a escribir una unión a través de un miembro de tipo Ty leer como tipo U, que se definiría de forma estándar en algunos casos (por ejemplo, al acceder a miembros de secuencia inicial común) y se definirá por implementación (más bien que indefinido) para el resto. Si bien era raro que los programas explotaran las garantías de la CEI con objetos reales de tipo sindical, era mucho más común explotar el hecho de que los punteros a objetos de origen desconocido tenían que comportarse como punteros a los miembros del sindicato y tener las garantías de comportamiento asociadas con ellos.

Un ejemplo simple y muy útil es ...

Imagina:

tiene un uint32_t array[2]y desea acceder al 3er y 4to byte de la cadena de bytes. que podría hacer *((uint16_t*) &array[1]). ¡Pero esto rompe tristemente las estrictas reglas de alias!

Pero los compiladores conocidos le permiten hacer lo siguiente:

union un
{
    uint16_t array16[4];
    uint32_t array32[2];
}

técnicamente esto sigue siendo una violación de las reglas. pero todos los estándares conocidos admiten este uso.