Bonjour,
 
Je travaille sur du code VBA où à un moment j'utilise un énorme tableau d'élément chacun de taille d'1 octet. Le problème c'est que je n'ai besoin que des 4 premiers bits de l'octet par exemple et comme la mémoire utilisée pour stocker ce tableau est trop importante je voudrais réduire tout ça.
Mais je ne sais pas si c'est possible de stocker uniquement quelques bits et non un octet entier. J'ai testé avec des boolean mais ce type prend 2 octets en VBA !!  
Je pensais alors faire une DLL avec un autre langage qui me permettrait de réduire la taille. Est-ce faisable ? Si oui quoi prendre ? VB.Net ne permet pas non plus il me semble de faire cela. Et si je pouvais éviter l'assembleur ça serait pas plus mal.  
 
Merci

idée en passant:
Pourquoi ne pas coder deux informations dans un élément du tableau?
du genre 1er element = 1ere info *2^4 + 2eme info

Effectivement c'est pas bête. Mais ça ne marcherait que pour 2 ou 4 bits, si j'en veux 5 ça devient difficilement gérable.

Le plus probable c'est qu'un tableau d'octets soit en fait un tableau d'entiers codés sur 4 voire 8 octets...  Question subsidiaire: pourquoi tant de données à traiter? Peut-être faut-il regarder si vraiment tu as besoin de toutes ces infos en même temps...

J'ai vérifié en créant un tableau de Byte il ne stocke bien qu'un octet par élément (en regardant la taille prise en mémoire vive du programme avant/après création).
 
J'ai tant de données car le programme fait toutes sortes de traitement sur un plan dans Visio. En gros on fait une matrice du plan avec une unité de base d'1m je crois sur des plans qui font plusieurs km de côté. On ne peut pas augmenter la taille de l'unité sinon on perd en précision.
 
Et avoir autant de données ça doit augmenter les risques de voir les données découpées un peu n'importe comment en mémoire et donc plus lent à les rassembler.
 
 
Edit : Ca existe un logiciel qui permet de voir où sont les données en mémoire ? Enfin oui ça doit exister mais un où je puisse retrouver mes données facilement.

Tu as un débug en VB il me semble.
 
Mais vu que c'est des accès rams, tu vas galérer pour t'y retrouver.

Le debug VBA me permet juste de savoir le contenu d'une variable et c'est tout. J'aimerai au moins avoir son adresse pour voir comment sont organisées mes données.

Si tu commence à vouloir jouer avec la mémoire passe au C, ca sera plus rapide et plus simple
 
A propos si tu as besoin de 5 bits à ce moment tu as pas le choix tu alloues un octet, tu vas pas commencer à allouer des octets et remplir les bits d'affilés.  
Sinon bonjour la galere quand tu va vouloir y acceder en mémoire.  
Je voudrais les derniers bits de celui la et les 2 premiers de celui ci o_O
En C okai mais en vb, j'ai un doute ( bon j'y connais pas grand chose aussi ^^)

Oui évidemment c'est ingérable pour 5 bits par exemple.

Donc ça serait possible de faire en C une DLL que j'appelerai depuis mon programme ? Mais j'arrive pas à trop à voir le lien entre les 2. Il faudrait que le C crée la matrice et propose une méthode du style get(i,j) pour que le VBA récupère la valeur ? Et pareil avec un set pour le remplir.

euh je donnais juste mon avis ^^.
Je ne connais pas du tout les liens entre C et VB.
Juste que quand je joue avec la mémoire, je préfère le faire en C.
Si tout tes données sont codées sur le même nombre de bit, alors l'accès est assez simple
Bon pour 5 bit c'est toujours plus chiant que 4 (car sinon tu fais un tableau de char et c'était réglé)
Si tu veux à tout prix 5 bit sans gachis, à ta place je ferrais un tableau de char, et une procedure d'acces
( vu que 4<5 tu sais que dans tout les cas tu vas devoir recoller des morceaux (au maximum 2))
 avec un calcul du genre
tab[n/4] tu sais dans quel case va commencer le 1er morceau
avec n mod 4 tu sais quel est le 1er bit
et avec un addition du genre:
1 morceau pondéré par n mod 4 + 2eme morceau
tu devrais arrivais à recoller les bouts ^^
 
ouai je sais c'est moche, mais j'ai jamais prétendu faire propre

sinon, est-ce que le gain en place apporté justifie une telle gymnastique ? si c'est pour gagner quelques centaines de Ko, ça vaut ptet pas le coup de se casser le cul non ?

Merci xme. Je vais tenter de faire une DLL en C.
Mais plutot de stocker ça dans un char c'est pas mieux de stocker ça dans le plus gros type possible afin d'avoir le moins de trous/chevauchements possibles ?
Par contre j'ai peur que la lecture prenne beaucoup plus de temps...

On est largement en Mo.
Les plans peuvent faire 5x5km. Pour le moment l'unité est 1m donc 25 Mo mais on voudrait améliorer la précision dans le futur. Si on passe à 25cm on arrive à 400 Mo et là ça commence à faire.

vu l'outil que tu souhaite faire effectivement passe sur un langage compilé (vb.net ou C# par exemple).
 
Ensuite n'utilise que des entiers (32bites) puisque c'est le format par défaut utilisé par les processeurs (et si tu prend autre chose il va convertir en entier lors de l'éxecution.
 
Si ton programme est toujours trop gourmand,  tu pourra jouer avec des ET logiques pour stocker plus d'une valeur dans un entier : dans ton cas 8 valeurs de 4 bits chacune.
 Ca complexifie le code mais c'est envisageable (et pas trop lent)

J'ai déjà implémenté la solution de xme pour 4 bits avec une DLL en C++. Mais il faut que le nombre de bits soit paramétrable donc je vais améliorer ça en stockant les bits dans des entiers les uns à la suite des autres.
 
C'est quoi xspawn_lpc l'histoire du AND qui stocke plus de valeurs ?

tu as un entier I du type : AAAABBBBCCCCDDDDEEEEEFFFFGGGGHHHH (en binaire)

 
idem pour les autres. Bien évidement tu peut travailler avec des nombres plutôt que les chiffres binaires mais comme cela, sa permet de voir ce qui se passe.
 
Si tu n'as pas tout compris, je t'invite à aller lire de la doc sur la base du codage en binaire

Ah oui bien sur. Je croyais que tu parlais d'une méthode "magique" pour compresser encore plus de valeurs dans un octet.
Mais c'est en gros ce que j'utilise pour stocker 2 nombre de 4 bits dans un octet.