Allocation mémoire optimisée au niveau bit

Bonjour,
J'aimerais savoir si vous savez si il existe une fonction d'allocation qui soit optimisée au niveau des bits. Je m'explique : habituellement, quand je déclare int i = 5 par exemple, je n'utilise que 3 bits sur les 32 (ou 64 ). Existe t'il une fonction d'allocation qui me permettrai de récuperer les 29 bits restant pour d'autres allocations ? Ayant déja beaucoup cherché sans succes je pense ecrire cette fonction moi meme, mais cela me semble assez compliqué , car il me faudrait utiliser des masques pour récuperer les differentes valeur stockées dans un mot mémoire. Qu'en pensez vous ?
Merci

Je pense que plutôt que d'utiliser le surplus, il faudrait commencer par faire un code le plus "mince" possible.

Dans ton exemple du int, utiliser plutôt un short.

Après je ne sais pas s'il existe des fonctions pour récupérer les espaces non utilisés, mais je ne pense pas.

Pour réaliser cette fonction, il faudrait utiliser des listes chaînées je pense si tu veux stocker des données à cheval sur deux espaces mémoires, donc au final je ne sais pas si tu gagnes vraiment de la place.

BSans :

Citation:

---

Pour réaliser cette fonction, il faudrait utiliser des listes chaînées

---

le(s) pointeur(s) de chainage risque(nt) de faire perdre plus de place mémoire qu'on peut espérer en gagner.

wilder :

Citation:

---

J'aimerais savoir si vous savez si il existe une fonction d'allocation qui soit optimisée au niveau des bits.

---

Rien de standard.
Au niveau des bits, il n'y a guère que les champs de bits des structures (mais attention à la portabilité) et la gestion personnalisée de masques (solution probablement préférable).

plus généralement, avant d'envisager ce genre de choses (extrêmes) il faut d'abord savoir optimiser son code et ses variables..

Si vraiment l'usage de la mémoire devient un problème insurmontable, penser éventuellement à ce genre de choses..

Est-ce le cas ??

J'ai plutôt l'impression que le PO (comme pour de l'optimisation de code où beaucoup pensent que cela passe par optimiser les if ou autres choses) pense gagner en faisant ce genre de manips dans un cas "ordinaire"...

Et pour ce genre de cas c'est à proscrire (non portabilité, lisibilité médiocre voire difficile), sauf à utiliser des short ou des char (si on ne dépasse pas 255).

Pour représenter tous les entiers de 1 à 255 un char convient tout à fait.. Et on a déjà économisé 3 octets..

Citation:

---

Envoyé par souviron34

Pour représenter tous les entiers de 1 à 255 un char convient tout à fait.. Et on a déjà économisé 3 octets..

---

Ca suppose que char est unsigned par defaut, ce qui n'est pas toujours le cas. Le standard garantit que char peut contenir des valeurs jusqu'a 127 uniquement.
De plus, utiliser un char pour faire un "petit entier" va entrainer des tas de conversions de char vers int.

oui mais si la place de stockage est importante..

D'autre part qu'il soit signé ou non, au pire on ira de -127 à +128.. Il y a toujours 255 valeurs... Ou alors faut que je révise fondamentalement la noton de bit et d'octets...

Ça fait 256 valeurs, non? -128 à +127 ou 0 à 255...

Encore que, je ne sais plus si la norme garantit que -128 soit possible...

Citation:

---

Envoyé par souviron34

D'autre part qu'il soit signé ou non, au pire on ira de -127 à +128.. Il y a toujours 255 valeurs...

---

256 valeurs, d'accord, mais tu as ecrit:

Citation:

---

eprésenter tous les entiers de 1 à 255

---

Un signed char peut representer les entiers de -127 a 127, un unsigned char peut representer les entiers de 0 a 255.

vi vi ok :oops:

256 valeurs..

M'enfin pour lui qui se posait la question de stocker la valeur 5...

D'ailleurs, les images (la plupart des formats, y compris mpeg) sont des buffers de char ou unsigned char..

Citation:

---

Envoyé par diogene

Au niveau des bits, il n'y a guère que les champs de bits des structures (mais attention à la portabilité) et la gestion personnalisée de masques (solution probablement préférable).

---

Tant qu'il s'agit de mémoire interne, il n'y a pas de problèmes de portabilité. Les problèmes apparaissent si on fait des interfaces avec des champs de bits (mémoire physique, fichiers, réseau etc.). là, effectivement ce n'est pas portable.

Merci de vos avis. Je pense que je vais réfléchir encore un peu avant de me lancer, bien sur je comprend que ce soit a faire en dernier lieu, mais je vais quand meme le faire au moins pour voir le résultat.