Reprise du message précédent :
bon.. lol
 
 
pour le printf("%x" ); si je fais ca sur un int je n'optient pas une adresse, j'obtient ca uniquement sur un pointeur, logique vu qu'un pointeur contient une adresse lol. c'est pour ca que je trouve pas ca très logique que x de p[x][] contienne une adresse et je parle pas de la sienne hein..  
 
pour qsort dans le cas d'un p * [] bein il intervertit les pointeur , et ca ca me pose pas de problème au niveau de la fonction de comparaison.
 
c'est pour le tableau p[][] que ca pose problème, il intervertit quoi ? bonne question lol si jme base sur mon résonnement d'au dessus il intervertit aussi des pointeurs de char c'est ca qui est fous    
 
 

printf("%x" ) t'affiche un int en valeur hexa. point.
 
si tu passes un int tu as la valeur d'un int.
si tu passes un pointeur tu as -par chance- la valeur du pointeur (because taille int == taille adresse, ce qui n'est pas toujours le cas).
 
si avec un printf("%x",t[.... tu vois ce que tu penses être une adresse marche c'est parceque le compilo t'as sorti l'adresse vu que c'était à ce moment ce qui tu est le plus censé vu le type de 't')
 
un 't[][]', avec printf("%x",t[i]) te donnera une adresse.
un 'int t[]', avec printf("%x",t[i]) te donnera la valeur de t[i] est non son adresse, printf n'en sait rien c'est le compilo qui l'a passé en paramètre.
 
ensuite pour avoir une adresse formattée correctement avec printf, c'est %p pas %x (mais on s'en fout ça reste compréhensible).
 
la chose qu'il faut que tu comprennes c'est que printf il affiche ce que est sur sa pile, et si tu mets des conneries il t'affiche des conneries, ça ne prouve rien en soit.
 
et si je te dis qu'avec un:
 
t[100][16]
printf("%x", t[0]) t'afficheras une valeur, mettons 11000
et que
printf("%x", t[1]) t'afficheras 11010.
 
parceque le compilo aura passé automatiquement et implicitement l'adresse de l'élement t[0] et t[1], sous-entendu t[0][0] et t[1][0].
 
tu commençes a saisir où il faut que je te le fasse en décimal ?

%p

 
vi je l'ai mis
 
mais j'avoues qu'il fallait le calmer beaucoup plustôt sur le "mais printf y dit que....."

si on peut même plus croire printf ou va t-on    
 
moi j'essayais de comprendre avec mes (pauvres) moyens..
 
ok pour la leçon printf lol
 
mon erreur venait du fait que j'imaginais mal les tableaux à plus d'une dimention je crois.
 
le fait de voire un tableau t[2][2][2] par ex comme un t[8] et la je suis ok pour mon strcmp.
 
je sais pas si c une bonne idée de voir ca comme ca mais au moin ca me gêne plus lol.
 
j'aurais quand même compris quelques petites choses au passage,  
 
merci bien    
 

mais push, comme avec un tableau tout est contigü t[2][2][2] est semblable à t[8]

 
voili voilou on arrive au bout. (enfin à peut près...)
 
donc avec 'char t[100][16]' et 'char *t[100]', pour chaque, quel est la taille en octet des éléments manipulés par qsort (on supposera une machine à adressage 32bit ) ? (histoire d'être sûr que tu comprennes)

qsort n'a aucune idée de ce qu'il manipule

tout à fait, c'est pour ça qu'on lui passe la taille d'un élément (je veux voir si il a bien tout saisi)

dans le cas du [][] on lui passe la taille d'un élément donc la taille d'un char, 1 octet. Et pour le *[] la taille d'un élément donc d'un pointeur, 4 octet.
 
   
 

heu bon....
 
je me suis mal exprimé alors
 
supposons que tu cherches à trier 100 chaines de caractères:
 
dans la première version, tes chaines sont contenues, les unes derrières les autres dans dans un zone fixe de 16 octets chaqune (donc 15 caractères si on considère le NULL)
 
dans la deuxième, tes chaines sont en vrac en mémoire, et maintenues via le tableau de pointeurs.....
 
et donc quelle taille d'élément va manipuler qsort pour le premier cas ?

je dirais que qsort manipule des éléments de 16 octect dans le cas de t[100][16]
 
donc c'est pour ca que dans qsort comme taille d'élément je lui passe sizeof t[0], ca représente les 16 premier élément de ce tableau
 
pour un tableau t[2][2][2] en mémoire les données se suivent comme ca ?
 
000
001
010
011
100
101
110
111

valà c'est ça... (par contre le sizeof je vérifies que ça passe, moi je préfèrerai spécifier directement une taille de 16 octets)

 
merci d'avoir tenu jusqu'au bout  

wé mais on s'est relayé