Tableaux à deux dimensions - Page 1

J'ai vu ça dans la doc de TIGCC. Je l'ai transformé entre temps:
unsigned char (*mat)[TABLE_X]=NULL;
mat = calloc (TABLE_X+2, sizeof (*mat));
Mais voilà. J'aimerais pouvoir passer mon pointeur à une fonction qui permette d'allouer la mémoire. Je ne vais pas retourner ce pointeur mais juste y assigner le bloc (pointeur qui sera donc passé par référence)
mat); }

En gros:void alloue(unsigned char **mat)  {
 *mat = calloc (TABLE_X+2, sizeof (*mat));
}
void main(void)  {
 unsigned char (*mat)[50]=NULL;
 alloue(&

Mais ça ça me fait un warning, et je doute en plus de ça que ça fonctionne.
Warning: Passing arg 1 of 'alloue' from incompatible pointer type
Comment faire?
Parce que si je mets mat en variable globale, ça affectera beaucoup les performances? Sachant que c'est la matrice du jeu et qu'elle sera beaucoup utilisée...
Et l'effet de
unsigned char (*mat)[50];
est la déclaration de 50 pointeurs de type caractère non? Alors que
unsigned char *mat[50];
aurait déclaré un pointeur sur un tableau de 50 caractères?

moi je dirais plutot :
unsigned char (*mat)[50]; // pointeur de tableau de 50 caracteres
unsigned char *mat[50]; // tableau de 50 pointeur de caracteres

dans les deux cas mat est un : unsigned char * *

le bon code est en fait celui la :

void main(void) {
  unsigned char *mat[50];
  alloue(mat);
}

Je sais pas trop ce que tu veux faire, mais en tout cas, si tu prend mon code, alloue() alloue de la mémoire pour mat[0].

La taille n'est pas connue dans "alloue", si tu voulais allouer (TABLE_X+2) * 50 octets, ça ne marchera pas.

void alloue(unsigned char (*mat)[50])
 {
 mat = calloc(10,sizeof(*mat));
 }

void _main(void)
 {
 unsigned char (*mat)[50] = NULL;
 
 alloue(mat);
 }

La ça devrait être bon, mais tu perd l'avantage de ta fonction "alloue" qui était censé allouer 10 tableaux de N elements. Tu devrais plutot passer la taille à allouer en parametre, non ?

ca y est j'ai compris ce que tu voulais, c'est Vertyos qui a raison

Si tu veux 10 tableaux de N éléments, je propose le code suivant :

void alloue(unsigned char * * mat, int taille)
{
	*mat = calloc(1, taille);
}

void _main(void)
{
	int i;
	unsigned char * mat[10] = NULL;

	for (i = 0; i < 10; i++)
		alloue(&mat[i], N);	// N: A remplacer par le nombre d'éléments dans chaque tableau
}

Mais à ce moment là, la fonction n'est pas nécessaire (pour une ligne)

void _main(void)
{
	int i;
	unsigned char * mat[10] = NULL;

	for (i = 0; i < 10; i++)
		mat[i] = calloc(1, N);	// N: A remplacer par le nombre d'éléments dans chaque tableau
}

Tu peux aussi avoir recours à une astuce qui évite de faire plein d'allocations indépendantes :

void ** nouveau_tableau(int lignes, int colonnes, int taille_type)
{
	int i;
	void ** resultat;
	int taille_entete	=  lignes*sizeof(void*);
	int taille_ligne	= colonnes*taille_type;
	int taille			= taille_entete + lignes*taille_ligne;

	resultat = calloc(1, taille);
	for (i = 0; i < lignes; i++)
		resultat[i] = (char*)resultat + taille_entete + i*taille_ligne;

	return resultat;
}

En fait, on alloue en un bloc tout le tableau, plus un entête qui contient des pointeurs sur les lignes (pour l'accès avec la méthode C normale. Voici un exemple d'utilisation de ce tableau :

int ligne, colonne;
int ** table = (int**)nouveau_tableau(5, 8, sizeof(int));

for (ligne = 0; ligne < 5; ligne++)
	for (colonne = 0; colonne < 8; colonne++)
		table[ligne][colonne] = ligne+colonne;

Cet exemple alloue un tableau d'entiers, de 5 lignes par 8 colonnes, puis le remplit comme ca :

0 1 2 3 4 5 6 7
1 2 3 4 5 6 7 8
2 3 4 5 6 7 8 9
3 4 5 6 7 8 9 10
4 5 6 7 8 9 10 11

Nota : je ne sais pas si tigcc gère le qqc++. Si ce n'est pas le cas, remplace tous les "qqc++" par des "qqc = qqc +1"

spectras> Tu as oublié une balise [/i].
Moi je propose plutôt ce code : char (*tab)[NB_COL] = malloc(NB_COL*NB_LIGNES); Sûrement plus simple que le tien.

Oui, mais j'ai déjà croisé des compilateurs qui interprétaient pas correctement ce code (sous HP-UX, je crois que c'était). Alors pour être sûr, j'ai préféré détatiller.
(J'ai pas tigcc, donc je voulait pas prendre de risque)

Note que la fonction que j'ai mis au dessus peur être réduite à 4 lignes si on ne détaille pas les calculs intermédiaires.

Ah ? Curieux, pourtant c'est du C ANSI

Je viens de relire ton post ./7, et je surpris pas ta "nota" en bas... C'est vraiment bizarre qu'un compilateur ne gère pas l'opérateur ++... Enfin, si ça peut te rassurer, TIGCC comprend le C-ANSI et une partie du C99, avec en plus des extensions GNU.

TIGCC c'est GCC, alors t'as pas de soucis à te faire spectras

spectras :
Nota : je ne sais pas si tigcc gère le qqc++. Si ce n'est pas le cas, remplace tous les "qqc++" par des "qqc = qqc +1"

Évidemment qu'il le gère! TIGCC n'est pas totalement débile! N'importe quel compilateur C ANSI comprend ++!

Sasume :
spectras> Tu as oublié une balise [/i].
Moi je propose plutôt ce code : char (*tab)[NB_COL] = malloc(NB_COL*NB_LIGNES); Sûrement plus simple que le tien.

Oui.

spectras
: Oui, mais j'ai déjà croisé des compilateurs qui interprétaient pas correctement ce code (sous HP-UX, je crois que c'était). Alors pour être sûr, j'ai préféré détatiller.

Ben, si NB_COL est constant, il a intérêt à comprendre parce que c'est dans le standard ANSI C89 / ISO C90. Pour NB_COL variable, c'est du C99, mais GCC le gère déjà depuis longtemps.

(J'ai pas tigcc, donc je voulait pas prendre de risque)

Cf. ci-dessus.

HP-UX, leur spécialité c'est pas le respect des standards.
Et vu que je me suis fait la main là dessus au début, y'a toujours de vieilles résurgences

spectras
: HP-UX, leur spécialité c'est pas le respect des standards.

Si tu as utilisé le compilateur livré avec, ce n'est pas surprenant que ça ne marche pas, il n'est prévu que pour compiler le noyau HP-UX, donc ne gère qu'un sous-ensemble du C K&R. Pour du C standard, il faut soit le compilateur "C ANSI" vendu séparément, soit GCC.

J'aurais pas demandé mieux, mais c'était la première fois que je programmais en C, donc je ne savais pas ce qu'il en était.
De toute façon, j'étais pas admin, et vu la taille de mon compte, fallait pas espérer faire une install de gcc dessus...

OK, merci pour vos réponses. En attendant j'ai fait quelque chose qui ne va sûrement pas vous plaire! #define mat(x,y)     table[(TABLE_X*(y))+(x)] typedef unsigned char * TABLEAU; short Alloue(TABLEAU *table, PSPRITE *sprites, ECRAN *Ecran); [...] int main()  {      TABLEAU table=NULL;      if (!Alloue(&table,&sprites,&Ecran))               {           Libere(&table,&sprites,&Ecran);                                        //Les blocs non-alloués ne seront pas libérés           return Erreur("Mémoire insuffisante");      } } short Alloue(TABLEAU *table, PSPRITE *sprites, ECRAN *Ecran)     {      *table = talloc ((TABLE_Y+2)*TABLE_X);      if (!(*table))     return 0;            *sprites=talloc((SPRITE_LIMIT+2)*sizeof (SPRITE));      if (!(*sprites))           return 0;      Ecran->Tampon=malloc(LCD_SIZE);                                        //Un écran      if (!(Ecran->Tampon))                                                                 //Pas pu allouer           return 0;      return 1; } Mais bon ça marche. Je peux ensuite faire par exemple mat(x,y)=1, et ça me donne une syntaxe comme en vb...
Nota: PSPRITE c'est un pointeur sur une structure SPRITE (de 15 éléments dont une structure 4 bits pour les collisions ), ECRAN est une structure comprenant un buffer, un scrolling de base (au motif près) et un petit décalage (au pixel près). Voilà, vous savez tout
Maintenant y'a un autre problème...
Parfois je reçois des erreurs Protected Memory Violation lorsqu'il n'y a pas assez de mémoire (c'est assez rare, mais ça vient apparemment de malloc, qui parfois renvoie une connerie au lieu de renvoyer NULL si ça ne va pas). J'ai vérifié et revérifié le code de l'allocation, il n'a pas l'air foireux. A noter que mes programmes ne semblent pas être les seuls à planter dans ces cas. Avez-vous une solution, sachant que ça ne vient certainement pas de la ROM, étant donné que j'avais déjà constaté ces erreurs alors que j'ai réinstallé la 2.05 entre-temps?

Moi, je serai plutot du genre à faire un tableau à une dimension puis une macro du genre
#define TABLE(y,x) (table[DIMX*(y)+(x)])

En fait, j'ai évité un moment les tableaux à deux dimensions parce que je ne savais pas comment ils marchaient. Mais depuis, j'ai ma petite idée la-dessus, alors...

(au cas où, c'est exactement ce que je fais dans mon code)
Mais c'est pourri car cela assume que tu as toujours un TABLEAU s'appelant table passé en référence.

C'est que je n'utilisais qu'un tableau, sinon 2 méthodes:
1- une macro par identificateur
2- Un peramètre en plus dans la macro: TABLE(tbl,y,x) et le tour est joué...

ergl et puis si la taille en X dépend de la table tu es obligé de faire des trucs gore avec le préprocesseur

gore? Puisque je définis toujours les dimensions de la table avec des #define pour X et Y, la solution de prendre une macro par table peut suffire... Ou bien, ajouter le DIMX en paramètre de la macro, ça ne mange pas de pain...

Pollux :
ergl et puis si la taille en X dépend de la table tu es obligé de faire des trucs gore avec le préprocesseur

tbl##_X
Ce n'est pas vraiment un problème, ça.

beurk

J'ai pas dit que c'était un problème, j'ai dit que c'était gore Et ça pose problème si la table en question est 'level_table[ i ]', parce que level_table[ i ]_XDIM, le préproc il connaît pas Mais on peut continuer dans le gore avec une variable locale 'current_level = level_table[ i ]', et définir la macro current_level_XDIM

PS : C++ rulez struct Level { ...; const int xdim=20; } Ultra propre

TIGCC supporte const

Mais non, pas dans ce sens-là En C, const n'est qu'un moyen de rajouter des warning/erreurs (d'ailleurs j'aime pas trop, mais bon...), et le fait de déclarer 'const int x=20' ne te permet pas d'écrire 'int y[x]={};'. En C++, une variable const a à peu près le même comportement qu'un #define portant sur un entier ou un float, tout en évitant le bordel de namespace lié au préprocesseur ; en plus, ça permet de l'affecter à une structure.

Sans compter qu'on pourrait aussi redéfinir un opérateur [] pour la structure correspondant au niveau

Pollux :
PS : C++ rulez struct Level { ...; const int xdim=20; } Ultra propre

C99 rulez.
unsigned char (*mat)[ydim]; et même pas besoin que ydim (ni xdim) soit constant.

Quant au ##, regarde les sources de ld-tigcc, il y en a pas mal (pour faire des templates en C).

C99 rulez. unsigned char (*mat)[ydim]; et même pas besoin que ydim (ni xdim) soit constant.

Mais n'importe quoi!

C:\Documents and Settings\Paul>echo const int x=20; int y[x]; > z.c

C:\Documents and Settings\Paul>tigcc -S -O2 z.c
z.c:1: error: variable-size type declared outside of any function

C:\Documents and Settings\Paul>tigcc -std=gnu99 -S -O2 z.c
z.c:1: error: variable-size type declared outside of any function

Et idem si tu le déclares dans une structure j'imagine

Quant au ##, regarde les sources de ld-tigcc, il y en a pas mal (pour faire des templates en C).

Ne t'inquiète pas, je sais ce que c'est Ca m'est arrivé assez souvent d'en utiliser, mais c'est vraiment pas terrible : si tu mets des fonctions dedans, c'est complètement indébuggable. Et pour l'exemple qui nous intéresse, ce n'est pas du tout aussi flexible que 'const int xdim' puisqu'on est obligé de le mettre dans une variable donnée et de déclarer à la main, pour tous les noms de variables possibles, la largeur du tableau... En plus on a vite fait de se planter dans un copier coller

Pollux
: z.c:1: error: variable-size type declared outside of any function

Ben oui, il faut le mettre dans une fonction, évidemment... Tu t'attends que le compilateur lit dans tes pensées pour savoir combien de mémoire allouer dans l'exécutable ou la section BSS si la taille n'est pas constante? Et si la taille est constante, alors utilise #define, pas const.

Et idem si tu le déclares dans une structure j'imagine

Pas si la structure est locale.

Quant au ##, regarde les sources de ld-tigcc, il y en a pas mal (pour faire des templates en C).

Ne t'inquiète pas, je sais ce que c'est

C'est surtout à Thibaut que je m'adressais là.

Ca m'est arrivé assez souvent d'en utiliser, mais c'est vraiment pas terrible : si tu mets des fonctions dedans, c'est complètement indébuggable.

Justement, dans ld-tigcc, il y a des fonctions entières codées avec des ## (suivies d'une ligne pour chaque spécialisation (pour reprendre le langage des templates, parce que c'est ce que c'est en réalité)).

Et pour l'exemple qui nous intéresse, ce n'est pas du tout aussi flexible que 'const int xdim' puisqu'on est obligé de le mettre dans une variable donnée et de déclarer à la main, pour tous les noms de variables possibles, la largeur du tableau...

Voilà pourquoi je conseille toujours la syntaxe C99 qui met ça là où ça a sa place: dans la déclaration du type.

D'ailleurs, le C99 prévoit aussi le passage de tableaux à une fonction sans avoir à préciser manuellement la taille, avec la syntaxe int y[*]. Mais GCC n'implémente pas encore ça.

int y[] n'est pas une déclaration de tableau de taille indéfinie ?