Bonjour !
 
Je me pose une question toute simple concernant les tableaux à 2 (ou plus) dimensions. En effet, je dois manipuler des images RGB 24bits de 640*480. Pour l'instant, je stocke cela dans un tableau déclaré comme ceci :
unsigned char tab[640*480*3] . Ca fonctionne très bien, ca permet de faire des fread et fwrite et des memcpy en une seule étape.
 
Cepenant, c'est un peu plus pénible qu'un tableau déclaré comme ceci (point de vue répresentation "intuitive" ) :  
unsigned char tab2 [480][640][3];
 
Ma question est donc : lorsqu'on déclare un tab2 ainsi, est-ce que les blocs mémoires sont automatiquement côte à côte en mémoire? Je veux dire : Est-ce que appliquer un memcpy fonctionnera ?
 
Bien entendu je pourrais faire des copies avec 3 boucles for imbriquées mais c'est lourd (et certainement plus lent).
 
Merci d'avance !  

à priori, si tu ne demandes rien au compilo, tu n'as pas la garantie d'un alignement des données en mémoire... par contre tu as des options de compilation ou des pragmas qui te permettent de jouer avec ça... perso j'aime pas trop les dimensions multiples, c'est plus rapide à l'execution de bosser avec une seule dimension

perso je te conseille quand meme la version en [480 * 640 * 3]. Apres tu peux te faciliter le boulot en laissant comber les char au profit d'une struct, c toi qui voit

ah bon?
 
pouvez-vous justifier un peu vos choix svp?
A la rigueur je fais une struct de 3 chars et un tableau à une dimension de 640*480 oui.

 
ben deja effectivement ca te permet d'envoyer gaiement tout a memcpy / truc. ensuite si tu dois faire du traitement par pixel tu t'en tire avec une seule boucle (au lieu de 2). C'est plus elegant.
 
 

 
+1
d'autant qu'un accès indicé avec un seul indice est sacrément plus rapide qu'avec 2 voire 3

Tiens si je fais une struct de 3 unsigned char, le compilo va surement aligner ca sur 4 octets. Ce qui me posera problème avec GTK et les fonctions gdk_draw_image ...  
Mais cet alignement est modifiable. Je vais réfléchir à vos propositions...

il me semble au contraire que si, d'ailleurs j'en ai la certitude.
deux arguments en faveurs :  
- sizeof qui veut que
  N = sizeof tab / sizeof tab[0]
- le calcul d'indice qui veut que tab[i] = *(tab+i)
 
donc à priori, je ne vois pas de problème

 
et les bordels d'alignement pour les structures?
ya pas le même genre de binz avec les tableaux multidimensionnels?
c'est juste une question hein...

non. le bourrage est intra-structure, un tableau de structure de pose aucun problème. donc un tableau de tableau non plus.

OK je vois ce que tu veux dire
Mais pour garantir l'alignement faut-il que le tableau soit déclaré statique, ou alors on est aussi sûr d'avoir les données alignées dans un tableau dynamique?

je pense qu'on en est sur. si tu considères les 2 règles que j'ai énoncé plus haut, alors tous les éléments de base sont de mêmes types et contigus, donc correctement alignés. j'ai même fait le test avec un tableau à taille variable C99, ça marche très bien

c'est bon à noter dans un coin ça...
merci

donc je te laisse conclure sur la question initiale

N'empêche que ça reste plus lisible (et surement + pratique) d'utiliser une structure PIXEL encapsulant 3 char.

ça c'est à lui d'en juger. rien ne tempèche de faire un typdef, seule le problème de recopie reste

On gagne vraiment beaucoup avec un tableau unidimensionnel? (edit : point de vue vitesse d'exécution)

boaf depend de ce que fais le compilo, si jamais il s'amuse a recalculer l'indice a chaque fois ou non....Si ton compilo est completement pourry alors ouais tu peux y gagner, sinon c surtout une question de confort

tu veux dire par rapport à un tableau multidimensionnel ? non, la preuve est faite que c'est la même chose, seul le calcul d'adressage change, c'est infinitésimal). Faut pas faire la parano, vous (et je) programmez comme des pieds, si vous commencez à faire de la parano là dessus, c'est ce que je nomme amicalement de la « masturbation intellectuelle de newbie »