Hola buenas, estoy arrancando con el tema de campos de bits y tengo el siguiente problema que no lo estaría entendiendo del todo:

Realizar un programa que permita almacenar la información de 10 los diez
productos que contiene un depósito en stock, por cada uno se debe
almacenar:
 Código (1 a 10)
 Cantidad que puede variar entre 0 y 500
 Si es Nacional o importado
Definir la estructura de forma de optimizar lo más posible el uso de la
memoria.

Espero me puedan ayudar a resolverlo para ver como es que se resuelven gracias.

Hola, ahí mande el código con lo que hice hasta ahora ( en comentarios están las dudas)

[/code]

Muchas gracias por tomarte el tiempo, ya pude comprender un poco mas el tema.

¿Qué ha pasado?
Le has dado unas directrices a C en tu construcción del mapa de bits y ha intentado acomodarlo como ha podido.
¿Cómo lo ha acomodado?
Vamos a reducir el programa a la mínima expresión:

#include <stdio.h>
 
struct s_producto {
    unsigned char codigo : 4;
    unsigned short cantidad: 9;
    unsigned char procedencia: 1;
    unsigned char bas: 2;
};
 
union u_producto {
    struct s_producto producto;
    unsigned short int empaquetado;
};
 
int main() {
    union u_producto vec = {0};
 
    printf("tamanno del mapa de bits: %lu bytes\n\n", sizeof(vec.producto));
 
    vec.producto.codigo = 0xF;
    printf("codigo     : %08X\n", vec.empaquetado);
 
    vec.producto.procedencia = 0x1;
    printf("procedencia: %08X\n", vec.empaquetado);
 
    vec.producto.cantidad = 0X1FF;
    printf("cantidad   : %08X\n", vec.empaquetado);
 
    vec.producto.bas = 0x3;
    printf("basura     : %08X\n", vec.empaquetado);
}

Resultado:

Sólo veo código. Vamos a abrir el rango.
En vez de

union u_producto {
    struct s_producto producto;
    unsigned short int empaquetado;
};

ponemos

union u_producto {
    struct s_producto producto;
    unsigned int empaquetado;
};

y resulta en


Podemos ver que alineó codigo en 2 bytes (aunque solo tuviera 4 bits) y cantidad también la ha alineado en otros dos bytes. Ya te digo también que he estado buscando procedencia y basura y no los he encontrado, pero están ahí. En el mejor de los casos está usando un byte en otro sitio para guardar esa información.

Por otra parte ocurre una cosa muy interesante. Si juntamos todos los unsigned char dentro del mapa de bits la cosa cambia:

struct s_producto {
    unsigned short cantidad: 9;
    unsigned char codigo : 4;
    unsigned char procedencia: 1;
    unsigned char bas: 2;
};

El resultado es el siguiente:


Vamos a exprimir un poco más el mapa de bits. ¿Qué pasaría si hubieras usado unsigned short en todos los tipos de datos dentro del mapa?

struct s_producto {
    unsigned short cantidad: 9;
    unsigned short codigo : 4;
    unsigned short procedencia: 1;
    unsigned short bas: 2;
};

Esto da como resultado:


De hecho te recomiendo quitar bas, porque no se usa.

En estructuras más complicadas sí que se usan bits para alinear la estructura interna, y solo tienen ese propósito, y estos son anónimos, no tienen nombre. Por ejemplo:

struct mapa_bits {
    unsigned dato: 3;
    unsigned: 4; // hueco de 4 bits sin nombre
    unsigned dato_2: 7;
}

Como dato curioso también existen los anónimos de 0 bits. Estos lo que le indican al compilador es que alinee los campos de bits que le siguen a una potencia de dos. De nuevo todo esto es para facilitar al procesador el movimiento de datos en la memoria.

Por ejemplo:

struct s_producto {
    unsigned short cantidad: 9;
    unsigned short: 0;
    unsigned short codigo : 4;
    unsigned short procedencia: 1;
};

Me devuelve el siguiente resultado:


¿Qué quiere decir todo esto?
No es buena idea usar union de esta forma, es decir, para empaquetar estructuras. Ya has visto que el compilador hace lo que quiere con ellas.

Más adelante te encontrarás que incluso guardar una estructura entera en disco o mandarla por la red te dará problemas porque al rescatarla leerás basura. Esto es debido, otra vez, a que el compilador hace lo que quiere con las estructuras y si a ti te las ha colocado de una forma en memoria, a otro puede que tenga sus miembros de forma diferente y por lo tanto se colocarán mal los datos. Pero también puede que en las dos máquinas las estructuras esté construidas igual y consigas bien la información.

Esto quiere decir que para serializar y deserializar estructuras manda al stream cada miembro de la estructura, uno a uno, en una secuencia dada. Recupera del stream uno a uno los miembros de la estructura en el mismo orden que los enviaste.

Por último, y como ya te habrás dado cuenta, dar diferentes tipos de datos a los miembros de un mapa de bits hace que el compilador intente agruparlos por tipo. Mezclarlos, como has visto, resulta en un desastre. Te recomendaría que uses unsigned y el compilador te lo va a acomodar todo en 32 bits.

Si necesitas un control muy fino de bits en memoria deberías pensar en operaciones de desplazamiento de bits junto a operaciones lógicas. Los mapas de bits son más para no gastar mucha memoria en números pequeños y caso es buen ejemplo de ellos. Un dato que perfectamente cabe en 4 bits, otro que cabe en 9 y otro que cabe en 1, puedes meterlo todo en 2 bytes en vez de gastar 12, que sería si los hubieras declarado como tres enteros diferentes.

Los campos de bits se ven mucho más en sistemas embebidos y microcontroladores.

Como ya te recomendaron, es mejor que evites los campos de bits si puedes, ya que no tienes casi ningún control sobre la manera en que el compilador los almacena.

También hay unas cosas que creo que vale la pena comentar. Los compiladores tienen ciertas libertades con las estructuras, pero lo que hacen no es aleatorio, y además hay reglas que tienen que seguir. Si dejamos de lado de momento los campos de bits, tenemos algunas garantías con las estructuras: el compilador siempre colocará en memoria los campos en el orden en que los declaramos. Puede haber relleno (padding) entre algunos, pero el orden siempre se respeta. Y la dirección del primer campo es la misma que la de la estructura, es decir, está exactamente al inicio.

Luego, hay otras reglas no oficiales, pero que los compiladores en general siguen. Por ejemplo, los compiladores normalmente acomodan los campos de acuerdo a su alineación natural, es decir, en qué direcciones de memoria conviene que estén. Si para lograrlo deben meter bytes de relleno (padding), lo hacen. Esto en general se puede evitar declarándolos de manera que ya estén alineados (no basta con sólo agruparlos por tipo). No sé si quisieras información más detallada, pero como estás empezando en estos temas, a lo mejor te podría confundir.

Con los campos de bits es más complicado y depende del compilador y la arquitectura, pero tampoco es totalmente arbitrario. De nuevo, sin entrar en detalles, baste decir que tiene sentido la manera en que los está organizando y ordenando el compilador en este caso y que, aunque acostumbramos leer de izquierda a derecha, en realidad los dígitos se enumeran de derecha a izquierda.

En los últimos ejemplos, el problema principal  es, como ya te dijeron, el hecho de usar union. Y esto no sólo aplica a las estructuras, sino que, en general, se supone que sólo uno de sus miembros es válido en un momento dado: el último que hayas modificado. Es decir, si haces esto:

vec.producto.codigo = 5;

lo más correcto sería que, a partir de ahí, consideres a vec.empaquetado como inactivo o "inválido" y no accedas a él. Si después modificaras el otro miembro:

vec.empaquetado = loquesea;

ahora este miembro es el activo y vec.producto se inactiva, y así sucesivamente.

De hecho, en C++ es incorrecto acceder al miembro "inactivo" (aunque compila y en general funciona, técnicamente no es válido). En C se permite y a veces se hace, pero no se recomienda, pues puede dar pie a errores.

Finalmente, para ver la representación interna de una estructura, es mejor usar punteros a unsigned char, no unions, y menos mediante un miembro entero, pues ¿qué tipo de dato debería tener empaquetado, si no sabemos a priori cuál es el tamaño de la estructura producto_t? Eso es parte del problema que se está dando, ya que en el ejemplo la estructura ocupa 6 bytes, pero empaquetado es unsigned short int (2 bytes) o unsigned int (4 bytes). No es que procedencia y basura estén escondidos o perdidos; están ahí, pero empaquetado no tiene el tamaño suficiente para mostrarlos. Se podría cambiar a un tipo de dato de 64 bits (aunque ya no se podría usar el especificador %X para imprimirlos sino que habría que recurrir a la macro PRIX64), pero  de nuevo, esta no es una manera aconsejable de usar union y estamos adivinando qué tamaño tendrá la estructura.  Lo mejor, reitero, sería usar un unsigned char* que apunte a la dirección de vec.producto, y vaya recorriendo por sus bytes y mostrándolos. O en todo caso, si no quieres usar punteros, puedes hacer que empaquetado sea arreglo de caracteres como lo hacías originalmente:

	unsigned char empaquetado[sizeof(s_producto)];

y vas iterando, desde 0 hasta sizeof(s_producto) - 1:

	printf("%02X  ", vec.empaquetado[i]);

aunque, dado que la arquitectura x86 (y x86-64) es little-endian (es decir, se almacena primero el byte menos significativo, o más a la derecha), los datos te aparecerían de manera inversa a la que probablemente esperarías, por lo que tal vez sea mejor mostrarlos al revés, iterando desde sizeof(s_producto) -1 hasta 0.