Definition d'un "nom de tableau"
Le
candide
Ce que je fais là est un peu cavalier mais j'ouvre un fil pour répondre
au message de François, l'autre fil devenant vraiment trop anarchique.
Francois a écrit :
>
> « Le nom t d'un tableau est une *constante* de type pointeur dont la
> valeur est fixée une bonne fois pour toute au début de l'exécution du
> programme et n'est pas stockée en mémoire. »
>
> est-ce correct ? J'ai l'impression que oui bien sûr, mais je me trompe
> peut-être (sûrement).
Je ne comprends pas ton obstination à vouloir trouver une définition
parfaite de "nom d'un tableau", ce qui compte aussi c'est de savoir les
utiliser ces tableaux mais peut-être que tu ne pourras faire cela
qu'après avoir défini, ce en quoi on reconnait le matheux ;) .
Et maintenant tu compliques les choses en parlant non plus de tableau
mais de nom d'un tableau.
À mon avis, ta définition est totalement incorrecte même si je
vois bien l'idée.
"Un nom de variable est une constante" ? Bof, dans la
norme (que je la connais très mal, OK), les constantes et les noms de
variables (les identificateurs) ne sont pas dans la même catégorie de
"token" donc on ne peut pas dire formellement qu'un identificateur est
une constante.
"Un tableau est de type pointeur", c'est une horreur, un tableau est de
type tableau, c'est tout même si une expression de type tableau est,
dans certaines circonstances, convertie en pointeur.
La valeur de t est fixée une bonne fois pour toutes au début ? oui, me
semble-t-il et encore, je sens que certains vont chipoter.
"La valeur n'est pas stockée en mémoire" : à mon avis, non, un tableau
est un objet, comment on y accèderait sinon ?
Comme dit la faq de clc à propos de l'expression "un tableau est un
pointeur constant" (question 6.9) : un nom de tableau est constant dans
la mesure où on ne peut l'assigner mais une fois de plus, un tableau
n'est pas un pointeur.
au message de François, l'autre fil devenant vraiment trop anarchique.
Francois a écrit :
>
> « Le nom t d'un tableau est une *constante* de type pointeur dont la
> valeur est fixée une bonne fois pour toute au début de l'exécution du
> programme et n'est pas stockée en mémoire. »
>
> est-ce correct ? J'ai l'impression que oui bien sûr, mais je me trompe
> peut-être (sûrement).
Je ne comprends pas ton obstination à vouloir trouver une définition
parfaite de "nom d'un tableau", ce qui compte aussi c'est de savoir les
utiliser ces tableaux mais peut-être que tu ne pourras faire cela
qu'après avoir défini, ce en quoi on reconnait le matheux ;) .
Et maintenant tu compliques les choses en parlant non plus de tableau
mais de nom d'un tableau.
À mon avis, ta définition est totalement incorrecte même si je
vois bien l'idée.
"Un nom de variable est une constante" ? Bof, dans la
norme (que je la connais très mal, OK), les constantes et les noms de
variables (les identificateurs) ne sont pas dans la même catégorie de
"token" donc on ne peut pas dire formellement qu'un identificateur est
une constante.
"Un tableau est de type pointeur", c'est une horreur, un tableau est de
type tableau, c'est tout même si une expression de type tableau est,
dans certaines circonstances, convertie en pointeur.
La valeur de t est fixée une bonne fois pour toutes au début ? oui, me
semble-t-il et encore, je sens que certains vont chipoter.
"La valeur n'est pas stockée en mémoire" : à mon avis, non, un tableau
est un objet, comment on y accèderait sinon ?
Comme dit la faq de clc à propos de l'expression "un tableau est un
pointeur constant" (question 6.9) : un nom de tableau est constant dans
la mesure où on ne peut l'assigner mais une fois de plus, un tableau
n'est pas un pointeur.
Poser une question
Ben si. Elle n'est gardee que par le compilateur, et cablee dans le code
a l'execution. Dans tous les cas ou on voudrait se trimballer le tableau
d'un coin a l'autre du programme, tu tombes sur un cas ou celui-ci est
converti en pointeur, et c'est le pointeur que tu ballades.
Désolé, je ne vois pas où tu veux en venir. Je lis dans K&R :
By definition, the value of a variable or expression of type array is
the address of element zero of the array.
alors je ne vois pas comment il serait possible que cette valeur ne soit
pas stockée en mémoire.
ça veut dire quoi "se trimballer un tableau d'un coin à l'autre du
programme" ?
(tu veux dire l'"utiliser", par exemple le passer en paramètre d'une
fonction ou accéder à ses éléments, si c'est ça, ta formulation est
trompeuse et peut être interprétée de façon erronée par quelqu'un qui ne
sait pas encore bien ce qu'est un tableau).
Qu'est-ce que tu racontes-là ? Qu'est-ce que c'est que ces tableaux qui
se trimballent et ces pointeurs qui se balladent ? Tu es l'Apollinaire
du C ? tu parles comme ça à tes étudiants ? Tu vois bien que François
est en train de couper des bits en 4 alors pèse tes mots.
Tu manques furieusement d'imagination.
Joue avec ton compilateur.
Regarde le code machine qui resulte de
char a[] = "bonjour";
char *b = "bonjour";
Tu verras que dans le cas du pointeur, il y a une adresse memoire
explicitement reservee pour b, tandis que dans le cas du tableau, t'as juste
une etiquette qui traine sur le premier element du tableau.
C'est l'ambiguite de la notation tableau en C, qui sert a noter des
tableaux, et des pointeurs. En dehors des definitions de tableaux, celles
qui reservent reellement de la place, tout le reste n'est que pointeur.
Lorsque tu reserves de la place, tu vois clairement que le tableau lui-meme
n'en prend pas. Lorsque tu utilises le tableau, pour acceder a des elements,
ou pour le passer a une fonction, celui-ci est converti systematiquement en
pointeur sur le premier element, et tu reserves la place pour cette element.
Sinon, je t'emmerde mon petit gars. Et si t'es pas content, c'est pareil.
Mes etudiants, ils ne sont pas systematiquement arrogants, et oscillant
entre de la fausse naivete et des tentatives systematiques de prendre leur
prof en defaut. Et ils essaient reellement de comprendre, plutot que de
sans arret essayer de prouver qu'en fait, ils ont mieux compris, qu'on leur
explique mal.
Partant de la, c'est beaucoup plus facile de discuter avec eux.
Non, si je fais du C, le compilateur pour moi est une boite noire, je ne
m'intéresse pas à la façon dont le compilateur implémente telle ou telle
fonctionnalité, chacun son boulot, pour moi le comportement visible du
compilateur est défini par la norme et je n'ai pas à sortir de là,la
seule difficulté pour moi, pauvre programmeur du dimanche, étant de
comprendre la norme mais je ne vois pas pourquoi avec le temps je n'y
arriverais pas. Ma vision est celle d'un _utilisateur_ de compilateur,
comme un voyageur qui se déplace en voiture d'un point A à un point B
n'a pas besoin de savoir le nombre de cylindres du moteur. C'est le
b-a-ba de la conception logicielle, il y a les interfaces et
l'implémentation. Les cordonniers ...
Une fois de plus, ça te dérangerait de t'exprimer clairement. La
question était (autant qu'elle ait un sens comme l'a fait remarquer JMB) :
"la valeur d'un tableau est-elle oui ou non stockée en mémoire pendant
l'exécution du programme".
Bon l'"étiquette" en question pour reprendre ton vocabulaire inapproprié
c'est donc la trace en mémoire du tableau.
Il est possible que je sois passé à côté de quelque chose, je ne suis
qu'un programmeur du dimanche et je manque en effet d'imagination, mais
je ne vois pas comment on peut accéder à un objet s'il n'est pas stocké
en mémoire.
Ce que tu dis là est très approximatif. Comme tout le monde le sait, il
existe deux (ou trois, ce n'est pas très clair) exceptions à la
conversion, c'est autre chose que ton "tout le reste n'est que pointeur".
On le sentait venir.
Oui, je cherche à mettre le prof en défaut si je vois que l'assurance
avec laquelle il me répond n'est pas en rapport avec la maitrise qu'il
possède de la question ou même seulement avec la cohérence de ses
réponses. Je n'aime pas qu'on fasse semblant et qu'on le reconnaisse pas.
Et au lieu de faire de la polémique stérile, si tu nous répondais à la
question de François, ce que moi, programmeur du dimanche, j'ai
humblement (oui !) tenté de faire ?
En fait, comme me l'a fait remarquer Candide je m'entête à vouloir
définir un tableau. Mais en plus, c'est peine perdue car je ne maîtrise
pas les termes que j'utilise pour ma définition (nom, constantes etc.).
Du coup, comme l'a dit Jean-Marc Bourguet, on ne sait pas de quoi je
parle, et pour cause, moi même en vérité je ne sais pas exactement de
quoi je parle.
Ceci étant, j'avais malgré tout des idées précises que je voudrais vous
exprimer et vous soumettre. Donc je vais utiliser un *tout se passe
comme si*, ce sera plus précis et on va dire moins "idéologique". :-)
-------------------------------------------------------
Quand dans un code j'ai cette déclaration :
int tab[10] ;
et qu'il y a " tab " qui intervient après dans le code (" tab "
complètement isolé, pas de crochet juste à droite comme par exemple avec
" tab[2] ") *tout se passe comme si* :
1) "tab " était égal à l'adresse du premier élément du tableau
(l'élément 0). Cette adresse n'est pas connue au moment de la
compilation car quand je fais
printf( "Valeur de tab %p", tab ) ;
j'obtiens une adresse différente à chaque exécution du programme. En
revanche, cette adresse n'est pas modifiable au cours du programme, ce
qui fait que par exemple
tab = tab + 1 ; (c'est là une grosse différence avec les pointeurs)
n'est pas correct. [La valeur de l'adresse du premier élément de tab
n'est pas stockée dans la mémoire RAM (Bon ... ça c'est sans conviction,
d'où les crochets)]
2) Comme *tout se passe comme si* " tab " était égal à l'adresse du
premier élément du tableau, on peut faire des incrémentations et des
décrémentation de cette adresse qui suivent une arithmétique analogue à
celle des pointeurs. Je veux dire par là que *tout se passe comme si*
par exemple " tab+3 " était l'adresse de l'élément 3 du tableau (le
quatrième élément du tableau donc).
3) Si "tab[2]" intervient dans le code, *tout se passe comme si* on
avait " *(tab+2) " et là, confère 1) et 2) précédent.
-------------------------------------------------------
Êtes-vous d'accord avec ceci ? Soyez intraitables ! :-))
J'ai vraiment essayé d'être le plus précis possible sans employer des
termes que je ne maîtrise pas.
Merci encore pour vos réponses.
François