¿Por qué necesitamos C Unions?

¿Cuándo deberían usarse las uniones? ¿Por qué los necesitamos?

Los sindicatos a menudo se utilizan para convertir entre las representaciones binarias de enteros y flotantes:

union { int i; float f; } u; // Convert floating-point bits to integer: uf = 3.14159f; printf("As integer: %08x\n", ui); 

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

Las uniones también se usan a veces para implementar pseudopolymorphism en C, dando una estructura con una etiqueta que indica qué tipo de objeto contiene, y luego uniendo 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 de la struct S sea ​​de solo 12 bytes, en lugar de 28.

Los sindicatos son particularmente útiles en la progtwigción integrada o en situaciones donde 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 puedes acceder al registro de la siguiente manera:

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

La endianidad (orden de bytes) y la architecture 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 progtwigción de bajo nivel del sistema es un ejemplo razonable.

IIRC, he usado uniones para descomponer los registros de hardware en los bits de los componentes. Entonces, puede acceder a un registro de 8 bits (como lo fue, en el día en que hice esto 😉 en los bits de los componentes.

(Olvidé la syntax exacta pero …) Esta estructura permitiría acceder a un registro de control como control_byte o vía bits individuales. Sería importante asegurar que los bits se correlacionen 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 reemplazo de la herencia orientada a objetos.

P.ej

  Connection / | \ Network USB VirtualConnection 

Si desea que la “clase” de conexión 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 a los miembros de datos que son mutuamente exclusivos compartir 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 una sola 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 de los usos. Simplemente haz grep union /usr/include/* o en directorios similares. La mayoría de los casos la union está envuelta en una struct y un miembro de la estructura le dice a qué elemento de la unión tiene acceso. Por ejemplo, checkout man elf para 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 parafraseado, por lo que puede no ser exacto). Se usó para almacenar elementos de lenguaje en un intérprete que construí. Por ejemplo, el siguiente código:

 set a to b times 7. 

consta de los siguientes elementos de lenguaje:

  • símbolo [establecer]
  • variable [a]
  • símbolo [a]
  • variable [b]
  • símbolo [tiempos]
  • constante [7]
  • símbolo[.]

Los elementos del lenguaje se definieron como valores ‘ #define ‘ 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 la siguiente estructura se usó para almacenar cada elemento:

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

luego 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, los tamaños reales dependen de la implementación).

Para crear un elemento “establecer”, usaría:

 tElem e; e.typ = ELEM_SYM_SET; 

Para crear un elemento “variable [b]”, deberías usar:

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

Para crear un elemento “constante [7]”, usarías:

 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 str y val no son contiguos en la memoria, de hecho 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 0x1010 y enteros y los punteros son a la vez 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 | | +-------+ 

Diría que facilita la reutilización de la memoria que podría usarse de diferentes formas, es decir, guardando la memoria. Por ejemplo, le gustaría hacer alguna estructura “variante” que pueda guardar una cadena corta así como un número:

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

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

Al usar 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. Puede ser cierto, que puede hacer cosas similares lanzando un puntero vacío, pero la unión hace que sea mucho más accesible, así como el tipo seguro. Estos ahorros no suenan masivos, pero está guardando 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 mensajes donde enviaría diferentes tamaños de mensajes, pero incluso entonces probablemente haya mejores y más alternativas amigables con los progtwigdores.

Los sindicatos son un poco como tipos de variantes en otros idiomas: solo pueden contener una cosa a la vez, pero esa cosa podría ser un int, un float, 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 float, dependiendo de lo que hayas establecido más recientemente . Haciendo esto:

 MYUNION u; u.MyInt = 10; 

u ahora tiene un int igual a 10;

 u.MyFloat = 1.0; 

u ahora tiene un flotante igual a 1.0. Ya no tiene una int. Obviamente ahora si intentas imprimir printf (“MyInt =% d”, u.MyInt); entonces es probable que obtenga 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. Realmente no los necesitas el 95% de las veces, sigue con el código fácil de depurar.

Muchas de estas respuestas se refieren al envío de un tipo a otro. Obtengo el mayor uso de 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 struct padding son válidos, y grandiosos, inquietudes. He utilizado este cuerpo de código casi por completo en software integrado, la mayoría de los cuales tenía el 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 sea de 32 bits.

Ahora, dentro de esos 32 bits, puede designar los primeros 8 bits como un identificador del remitente del evento … A veces se trata del evento como un todo, a veces se diseca y se comparan los componentes. los sindicatos le dan la flexibilidad para hacer ambas cosas.

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

¿Qué pasa con VARIANT que se utiliza 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, utilicé 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 los operadores >> y <<, simplemente tuve que pasar por el índice diferente de mi matriz de caracteres.

Usé la unión 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 lo usé de esta manera:

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

No requiere desplazamiento para que el código sea más fácil de leer.

Por otro lado, vi un viejo código stl de C ++ que usaba la unión para stl allocator. Si está interesado, puede leer el código fuente de 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 de comandos de búfer 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 comstackdor esencialmente produciría una tabla de tamaños de estructuras (y posiblemente alineamientos), y una tabla separada de estructuras, nombres de miembros, tipos y compensaciones. El comstackdor no realizó un seguimiento de qué miembros pertenecían a qué estructuras, y permitiría que dos estructuras tuvieran un miembro con el mismo nombre solo si el tipo y el desplazamiento coincidían (como con el miembro q de struct x y struct y ). Si p fuera un puntero a cualquier tipo de estructura, p-> q agregaría el desplazamiento de “q” al puntero py obtendría un “int” de la dirección resultante.

Dada la semántica anterior, fue posible escribir una función que pudiera realizar algunas operaciones útiles en múltiples tipos de estructuras indistintamente, siempre que todos los campos utilizados por la función se alinearan con campos útiles dentro de las estructuras en cuestión. Esta fue una característica útil, y cambiar C para validar los miembros utilizados para el acceso a la estructura contra los tipos de las 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 esa brecha un poco (aunque no, en mi humilde opinión, así como debería haber sido).

Una parte esencial de la capacidad de los sindicatos para llenar ese vacío era el hecho de que un puntero a un miembro del sindicato 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. Mientras que el Estándar C89 no dijo expresamente que enviar un T* directamente a un U* era equivalente a convertirlo en un puntero a cualquier tipo de unión que contenga tanto T como U , y luego convertirlo en U* , ningún comportamiento definido del la última secuencia de lanzamiento se vería afectada por el tipo de unión utilizado, y el Estándar no especificó ninguna semántica contraria para un lanzamiento directo de T a U Además, en los casos en que una función recibe un puntero de origen desconocido, el comportamiento de escribir un objeto a través de T* , convertir el T* a un U* , y luego leer el objeto a través de U* sería equivalente a escribir un sindicato a través de un miembro de tipo T y lectura como tipo U , que se definiría de forma estándar en unos pocos casos (por ejemplo, al acceder a los miembros de la Secuencia inicial común) y Definido por la implementación (en lugar de Indefinido) para el rest. Si bien era raro que los progtwigs explotaran las garantías CIS con objetos reales de tipo sindical, era mucho más común explotar el hecho de que los punteros a objetos de origen desconocido debían comportarse como indicadores para los miembros del sindicato y tenían las garantías de comportamiento asociadas.

Un ejemplo simple y muy útil, es ….

Imagina:

tiene una uint32_t array[2] y desea acceder al 3 ° y 4 ° byte de la cadena Byte. podrías hacer *((uint16_t*) &array[1]) . ¡Pero esto lamentablemente rompe las estrictas reglas de aliasing!

Pero los comstackdores 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 respaldan este uso.