malloc, tableau, pointeur - Page 1

je viens de lire [urli]topics/17292-malloc[/urli] mais dans mon cas ca ne marche pas
en fait moi mon tableau je vais le realloc() plusieurs fois au cours du programme (c'est un unsigned char)
d'abord je le déclare comme ca :
unsigned char **lvl=malloc(W*H);
puis je le remplis comme ca :

for(i=0;i<(unsigned) (W*H);i++){
 		lvl[i%W][i/W]=*(BYTE*)(ptr++);
 		printf("%i-",lvl[i%W][i/W]);
 		if(i%W==0) printf("\n");
 	}

notes : le unsigned c pour eviter un warning, le printf c'était pour debugger
erreur : subscripted value is neither array nor pointer

donc j'essaye avec la methode Kevin Kofler :
memcpy(lvl,(unsigned char [W][H]) ptr,W*H);
erreur : cast specifies array type

le pointeur ptr renvoie vers une zone dans un fichier grace à un sym_entry et tout
(je suis pret a me passer de lvl[x][y] et a passer par le *(lvl + x + y*x_size_tab) )

et si tu virais le cast ?

La méthode dont te parlais Kevin doit être (unsigned char(*)[H])ptr...

Mais en principe, tu devrais inverser les indices de tableau et utiliser lvl[y][x] pour que ça soit équivalent à lvl[x + y*W] (et donc ça sera (unsigned char(*)[W])). Et à vrai dire, le plus simple dans ton cas ce serait de passer par un tableau de "unsigned char" et d'utiliser lvl[x + y*w] (quitte à faire #define map(x,y) lvl[(x)+(y)*W]), ce qui te permettra d'utiliser memcpy pour initialiser ton tableau par exemple.

Note : le unsigned c pour eviter un warning

J'en déduis que W et H ne sont pas constants... Alors essaye à tout prix d'éviter les multiplications et les modulos et remplace-les par des décalages ou des ET logiques : arrondis W et H au supérieur, puis prends leur logarithme en base 2; après ça, tu pourras utiliser #define W (1<<W_log) et #define H (1<<H_log) et le code généré par le compilo sera bien plus efficace (mais, si tu as de très grosses maps, il vaudra mieux t'arranger pour qu'elles aient des tailles puissances de 2 pour éviter de gâcher trop de place).

2> non les tailles varient jusqu'à 255 (grand maximum, je ne pense pas que ce nombre soit utilisé mais root(256)=16 ce n'est pas assez (pour faire rentrer W et H dans un meme octet)
les tailles varient effectivement et je vais realloc() la variable (si cela est possible, parce que c'est la premeiere fois que je me sers de ces fonctions) plusieurs fois au cours du programme (lecture d'une autre partie du fichier, qui sera plus ou moins grande)

(ce que j'ai appelé la méthode de Kevin c'est dans l'autre topic)
quant à l'inversion de x et de y, c'est pas grave. j'avais oublié mais je m'en serais vite rendu compte

1> j'ai essayé, ca me fait je sais plus une autre erreur, j'ai essaye aussi toutes les combinaisons de placements de '&' devant lvl et ptr

(ce que j'ai appelé la méthode de Kevin c'est dans l'autre topic)

Et si tu lisais d'abord ma réponse avant de me dire que j'ai tort?

Et j'ai rien capté à ton histoire de taille qui varie et qui va jusqu'à 255... J'ai pas non plus compris à quoi tu faisais exactement référence quand tu dis "non".

euh pour le 'non' c'est parce que j'avais l'impression que tu parlais de tres grandes tailles dans ton post
pour l'histoire du 255 :
dans un fichier ya la largeur (W) du niveau dans un octet puis l'octet suivant la hauteur (H tu avais sans doute compris) donc la hauteur et la largeur peuvent aller jusqu'a 255 chacun. comme je ne pense pas avoir de niveaux de dimensions 255 (trop grand) j'aurais pu ranger les 2 dimensions dans un octet mais cette fois ca serait trop petit
(je me suis a parler de ca qui peut sembler HS parce j'avais l'impression que tu croyais que W et H étaient tres grands : parce je n'ai pas compris pourquoi avoir recours au log en base 2)

Ha OK, non c pas une question de trop grand.

parce je n'ai pas compris pourquoi avoir recours au log en base 2

Ben l'intérêt c'est que pour multiplier par W (ce que le programme va devoir faire à chaque instruction) le compilo va juste avoir besoin de faire un décalage logique (assez rapide) au lieu de devoir faire une multiplication (bcp plus lent). Pour les modulos, c'est encore pire : le ET logique est très rapide, mais le modulo est très très lent.

Et à la limite si W et H sont aussi petits (<16) alors tu peux aussi les coder en dur dans ton programme (au lieu de les laisser variables). Ca peut accélérer encore le prog (à condition que W et H soient des puissances de 2), mais tu vas avoir des maps de 256 octets à chaque fois.

le ET qui remplace le modulo c'est :
a%b == a&(b-1)
si c'est cuila j'avais trouvé que ca marchait qu'avec les b pairs (en gros si b est impair (b-1) est pair est donc a&(b-1) se forcement un nombre pair)
mais le log en base 2 ca va pas ramer d'utiliser des nombres non-entiers (ou il faut que je force les tailles a etre puissances de 2 ?) ?
et puis sinon pourquoi utiliser #define si ca va varier ?

et pourquoi parles-tu de chaque instruction calculer W*H ? dans le for ? (si c'est ca je peux utiliser une variable intermediaire)

a%b == a&(b-1)

est-ce que ça ne marche pas uniquement si b est une puissance de deux ?
(j'ai pas vérifié, mais...)

ah oui (on ne m'avais pas prevenu et en plus je l'avais pas remarqué)

Je parlais de W et H puissances de 2, oui.
L'intérêt de passer par le log en base 2 est alors d'assurer au compilo qu'on multiplie bien par une puissance de 2.

et pourquoi parles-tu de chaque instruction calculer W*H ? dans le for ? (si c'est ca je peux utiliser une variable intermediaire)

Je ne parle pas de W*H, je dis que lvl[y][x] est transformé en lvl[x+y*W], donc on a bien une multiplication par W à chaque fois.

ah oui j'avais mal lu
mais sinon avant de parler d'optimisation (je ne rejette pas du tout, tes conseils sont tres interessants), comment copier la zone du fichier dans le tableau ?

NiTrO120 :
donc j'essaye avec la methode Kevin Kofler :
memcpy(lvl,(unsigned char [W][H]) ptr,W*H);

Ce n'est certainement pas ma méthode, parce que c'est faux.
Cf. le ./3 de Pollux.

NiTrO120
:mais sinon avant de parler d'optimisation (je ne rejette pas du tout, tes conseils sont tres interessants), comment copier la zone du fichier dans le tableau ?

Si tu fais un tableau plat (ma méthode, ou alors un tableau à 1 dimension comme suggéré par Pollux), tu peux utiliser un simple memcpy.

bon pour en revenir au log en base 2 je vois pas comment remplacer la multiplication (desole mais je suis un peu lent)

Si tes entiers sont des puissances de 2, tu peux les remplacer par des shifts. Mais laisser tomber, pour 2 octets (c'est tout ce que ça économise), ça ne vaut pas le coup.

pour 2 octets (c'est tout ce que ça économise)

Non, ça économise plein, plein de vitesse. Et c'est vraiment la base de la base pour faire du code un tantinet efficace (i.e. pas du code de newbie 5x plus lent que ce qu'il devrait être)

mhhh et comment on fait avec le log et le decalage ? (j'ai vraiment pas compris comment eviter la multiplication)

x*2ⁿ==x<<n

merci ca je savais quand meme, ce que j'ai pas compris c'est en quoi ca simplifiait de s'en servir

2 octets de moins, et plus rapide.

ouais mais ca prendra plus de place si W et H doivent absolument etre des puissances de 2 ...

Clair.

Oui, plus de RAM, mais ce sera plus rapide. A toi de voir.