Bonjour à tous, juste une petite question qui va s´en doute vous paraître trivial, mais bon...

Est-il préférable de déclarer un byte ou plutôt un tableau de 256 booléens?

En mémoire, c´est censé faire la même taille, mais on(je) aurait tendance à penser que le tableau prend plus de place.

Voilà, merci par avance.

dans presque tout les langages et presque tout les compilo, un booleen occupe un octet au moins. (sans compter qu´il n´y a que 8 bits dans un octet et pas 256).

Donc il vaut mieux déclarer des entiers et faire les manip soit même si tu veux énonomiser la mémoire. Mais si tu a besoin de 256 booleens (une seule fois), autant allouer un tableau, ça te fera moins de travail et ça sera plus efficace.

Par contre, il y a en C++ un objet (bitset je crois, dans bitset.h) qui permet de faire des tableaux de bits. Le seul problème c´est ce la taille de ces tableaux doit être connu à la compilation (car il s´agit de template).

Je confirme q´un byte (octet) n´est que de 8 bits.

Si tu veux faire un tableau de quelques booleens, utilise donc un tableau de char : ça te prendra un octet entier par boolean, mais ça aura le mérite d´etre rapide.

Evidemment, il se peut que tu aies cruellement besoin d´optimiser la mémoire (mais en as tu vraiment besoin ? Cela est utile si tu veux faire un tableau de plusieurs dizaines de millions de booleens au moins) ou alors des millions de tableaux plus petit.

Dans ce cas la, tu as plusieurs possibilités :
- le bitset proposé par Dnob, mais qui n´est pas encore completement standard : il est admis que dans les versions étendues de la STL (la STL de SGI)
- faire ta propre classe de bitset (c´est amusant a faire, a grand coup de & | ~ ...)
- si tu fais des paquets de 32 bits, tu peux utiliser un int comme conteneur par exemple, et faire une gestion de flags, a coup de piping | souvent associé a un tas de define.

Pour chacune de ces méthodes, il est nécessaire, pour extraire le bit, d´appliquer des masques.
ça va vite, mais ça va moins vite que si tu as un tableau de char que tu accedes directement !

J´ajoute que le type "bool" en C est en fait un int : jamais le C ne manipule nativement qu´un seul bit a la fois.

Mais pour conclure, as tu vraiment besoin d´otpimiser la mémoire a ce point ? Sinon -> Tableau de char ( char ou byte)

Une autre possibilité que j´ai oublié, c´est la compression des données des structures :

http://perso.numericable.fr/fvirtman/info/tuto/G_2_01_non_octet.cpp

Je me permet de rappeler aussi que c´est vrai un byte c´est petit, ca fait un octet.
Mais ton processeur NE SAIT PAS manipuler un octet. il ne sais manipuler que des donné de la taille d´un mot processeur. et donc ce n´est pas sur que tu ne perdes pas du temps d´exécution en fin de compte.

c´est apres, pour récupérer le bit (donc application de masque, ou alors shifting >> << ) que tu risques de perdre du temps.

(et d´un post sans conneries, depuis 15 minutes et d´un !)

Oups, je me suis en effet trompé, pour la taille du byte, ceci étant du au fait que le byte est compris entre [-128, 127], mais bon, j´étais fatigué, passons

En effet, je n´ai pas forcémment besoin d´optimisé à ce point, mais je programme sur téléphone portable en J2ME et la moindre optim est toujours bonne à prendre.

Sinon, je pense opté pour prendre le int comme conteneur comme l´a proposé Fvirtman. Par contre, je ne sait pas si je peux ajouté la compression des données des structures comme expliqué dans ton tuto (ça existe en Java?).

Pour les bitset, je connaissais pas, ça à l´air sympa mais je ne peux pas l´appliquer car il faut limiter au maximum le nombre de classes.

Merci à vous.

non, ca n´existe pas en java. Mais en java, tu as boolean dont la taille fait classiquement 1 octet et pas 1 bit.

Personnelement, j´utiliserais des booleans et je regarderais comment ca tourne apres. Si tu as besoin de faire plus petit, tu veras a ce moment la.

Je me demande si ce genre d´optimisation de la mémoire ne conduit pas à un gaspillage de mémoire :
Stocker un booléen sur un bit, ça implique d´utiliser un masque pour récuperer chaque "champ" de l´octet, donc ça fait une instruction en plus à chaque uttilisation; ce qui fait que sur tout les systèmes ou le code est stocké en ram, on utilise plus d´espace mémoire en utilisnt des bits à la place des octets.

blip, tout dépend de ton volume de donnée.
ton code n´est présent qu´une seul fois par objet donc si il prend (soyons fous) 1000 octet de place, tu commences a gagner de la place apres 1000 objet.
Que l´on soit d´accord, si tu as moins de 1000 objets, je ne vois meme pas l´interet de compresser la mémoire.

ah oui j´avais pas vu les choses come ça, merci d´avoir corrigé.