Boujour. Comment déclare t´on en C, un tableau de de X cases qui ont une taille de 1 bit ? Sans utiliser les champs de bit avec la commande struct.

en C t´est obligé quand tu défini 1 tableau de définir sa taille au moment ou tu le déclare,tu peut pas faire par exemple :
int tab[x][5] / /x tableau de 5 cases
sa va planter si tu met " X" comme taille.
mais il existe une méthode pour stocker des données dont on ne connait pas la quantité au préalable ( les listes , les arbres,si tu veux je peut t´expliquer)
mais c´est peut être pas ca ta question
j´ai peut être mal compris explique + en détail ta quest

Je veux faire un tableau de 5 cases avec des cases de 1 seul bit.

sinon pour faire un tableau comme tu le dit, avec un nombre indéfini de cases il faut utiliser les pointeurs puis faire une allocation mémoire avec la commande malloc

bah tu peux pas

Tu peux toujours créer ta propre classe pour gérer un tableau de bits : tu fournis la taille au constructeur et tu surcharges l´opérateur [] pour accéder à tel ou tel bit . ..

Merci

Ca sert a rien de gerer des cases de 1 bit.

Pourquoi tu tient vraiment a faire ca ?

La taille minimum pour un element de tableau est un octet ( 8 bits)

Bah si justement ca peut servir . .. regarde donc sur le net il y a plein de sites parlant des bits array ( d´ailleurs la plupart crée cette fameuse classe dont je parlais). Notamment en cryptographie ou en compression par exemple.

Grâce à ce genre d´outils il peut être possible de créer et gérer des variables de taille quasi infinie à condition de coder les opérations associées.

imagine la déclaration suivante :

BitsArray Key512bits(512);

Ca te permettrait par exemple de gérer des clés de cryptage, ou je ne sais quoi encore.

La classe s´occuperait elle même du codage d´une telle variable en passant par des octets forcément. Enfin je pense que ca peut faciliter grandement l´utilisation et l´écriture de programmes travailant sur des bitfields ( en surchageant la plupart des opérateurs : +, -, *, & etc...)

J´imagine bien que ce peut avoir une utilité quelquonce mais ici on est dans le forum " Creation de jeux" Donc dans notre contexte, gerer un tableau avec des bit ca sert a rien.

arf

La compression des données est utile dans tous les domaines y compris les jeux.

pour stocker 5 éléments, tu n´y gagnes rien : fait un tableau de char...

Apres, si tu veux faire des tableaux avec bcp de bits, alors oui, ça vaut le coup.

Y´a une structure toute faite dans les STL :
" bit_vector"

tu peux te renseigner dessus

sinon, pour manipuler des bits dans des variables, utilise les opérateurs bit a bit & | ^ et ~

ya un truc qui va pas dans l´histoire, le C++ une fois compilé il devient de l´assemleur pour le processeur et il utilise la ram, or à chaque adresse de la RAM c´est 1 octet qui est stoké soit 8 bits, le seul moyen de les dissocier c´est de faire un masque avec des opérateurs logiques,de ce fait le plus simple ( je pense) c´est pas d´utiliser le C++ pour faire ton programme mais de l´assembleur,car le compilateur fais parfois des trucs bizzar quand il sagit de travailler bits à bits.Quand un programme est simple vaut parfois mieux le faire en language assembleur,si le programme est court il sera + performant que venant du C++ compilé...

Altonfrere, tu sais il existe des libs toutes faites pour faire la compression Faut les utiliser.

Si tu t´embetes a faire ta compression avec tes clés de cryptages, etc , ben t´es pas pret de le finir ton jeu

Bon allez, si ca vous amuse de gerer des bits, pourquoi pas...

lapintade au lieu d´étaler ton ignorance devant tout le monde réflechit un peu à l´utilité que cela pourrait avoir.
Tu as un grand nombre d´objets a traiter, tu veux savoir lesquels tu as traiter. Ben si tu as 100 millions d´objets, que tu prends un char pour dire c´est traité, c´est pas traité, ca te fais un tableau de 100M. En utilisant des bits ca ne te fais plus que 12.5M

C´est très utile si tu fais un tableau 2D pour gérer une carte par ex. Tu as une dizaine de type possible de texture, tu codes ca sur 4bits, ben tu divise la taille par 2 en mémoire.
genre
0001 - neige
0010 - pierre
etc....

pour davidlebar :
Ecrire soit même de l´asm ce n´est pas toujours plus rapide. Les compilateurs d´aujourd´hui optimisent beaucoup plus que ce que tu ne pourrais faire toi même je pense.
Gérer le cache, les instructions en parallèle..

" en C t´est obligé quand tu défini 1 tableau de définir sa taille au moment ou tu le déclare"

queneni mon bon monsieur, et que fais tu de la programmation dynamique?

int * mon_tableau_dynamique

. .. Du code . ..

mon_tableau_dynamique = malloc ( Le_nombre_de_case_que_tu_veux * sizeof(int));

tadaaaa! et voila, ensuite tu t´en sert comme un tableau normal

à kookii, non ecrire en assembleur c pas tjrs plus rapide mais ceratins compilateur font de l´optimisation exemple si en C tu veut optenir une impulsion à front montant tu fais
{int i;
i=0;
i=1;
i=0;}
bah certains compilateurs optimisent ca et ca te donnent:
{int i;
i=0;}
et là ton front montant tu peut toujours l´attendre, alors que si tu programme en assembleur t´est sur de l´avoir ton impulsion, j´ai peut être tort mais personellement quand je programme en numérique et que je veut être sur de ce que ca marche je fais mon prog en assembleur,programmer en assembleur c´est peut être + fastidieux mais c´est plus sur pour certaines manipulations de bits.

Ben si tu as 100 millions d´objets

kookii, tu ose me dire que j´etale mon ignorance ( tu me donnais meme pas) ben toi tu te caches pas pour etaler ta connerie. Le jour ou tu aura un jeu qui aura 100 millions d´objets, tu m´appellera.

" Altonfrere, tu sais il existe des libs toutes faites pour faire la compression Faut les utiliser."

Donc on fait comme tout le monde, on a les mêmes libs et au final on utilise les mêmes algos de compression ? vachement pratique pour la protection ca ; ) Tu trouveras pas beaucoup de jeux qui n´utilisent pas leur propre format de fichiers ( structure et compression). Normal non ? on a pas envie de se faire ripper toutes les ressources Ou alors le jeu est dédié à être exploité, et le format est ouvert au public ( genre les Quake-like). Mais là c´est un cas particulier. De plus une lib " pro" c´est pas gratuit ou alors tu ne peux pas l´exploiter à des fins commerciales.

" Si tu t´embetes a faire ta compression avec tes clés de cryptages, etc , ben t´es pas pret de le finir ton jeu"
Et pourtant ca fait partie du développement ! Des libs propriétaires c´est toujours plus sûr que des lib extérieures. Déjà t´es pas sûr qu´elles seront maintenues, c´est pas forcément libre de droit ( rarement d´ailleurs) enfin bref...

Pour davidlebars29 :

Le but n´est pas de savoir comment seront manipulés les bits. Les opérateurs du C suffisent amplement ( ceux que JY² a énumérés). Mais le but d´une telle classe est justement d´encapsuler ces traitements et faciliter l´écriture/lecture du code utilisant cette classe!

davidlebars29 à pas tort, touts les ingénieurs te le dirons,un programme si il est très simple,l´assembleur programmé sera plus efficace que l´assembleur compilé du C++. evidement faut savoir sur quel µ-processeur tu travaille,les jeux d´instructions differents.

et donc un code source différent pour chaque plateforme

Altonfrere, tu sais tres bien qu´aucune protection n´est efficace. Lorsque tu as un developpement aux delais serrés tu vas a l´essentiel et tu reinvente pas la roue. De plus je pense que ca sert meme a rien de compresser les données, les jeux se contente de simlement les concatenés dans leur formats.

Enfin cette discussion est sterile, tout le monde oublie qu´ici on est dans un forum de developpement amateur, c´est pas le bon endroit pour parler de tout ca.