Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Definition d'un "nom de tableau"

81 réponses
Avatar
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.

10 réponses

1 2 3 4 5
Avatar
espie
In article <47db1ed3$0$15757$,
candide wrote:
"La valeur n'est pas stockée en mémoire" : à mon avis, non, un tableau
est un objet, comment on y accèderait sinon ?


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.

Avatar
candide
In article <47db1ed3$0$15757$,
candide wrote:
"La valeur n'est pas stockée en mémoire" : à mon avis, non, un tableau
est un objet, comment on y accèderait sinon ?


Ben si. Elle n'est gardee que par le compilateur, et cablee dans le code
a l'execution.


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.

Dans tous les cas ou on voudrait se trimballer le tableau
d'un coin a l'autre du programme,


ç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).

tu tombes sur un cas ou celui-ci est
converti en pointeur, et c'est le pointeur que tu ballades.


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.


Avatar
espie
In article <47dba1c0$0$13645$,
candide wrote:
In article <47db1ed3$0$15757$,
candide wrote:
"La valeur n'est pas stockée en mémoire" : à mon avis, non, un tableau
est un objet, comment on y accèderait sinon ?


Ben si. Elle n'est gardee que par le compilateur, et cablee dans le code
a l'execution.


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.


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.

Dans tous les cas ou on voudrait se trimballer le tableau
d'un coin a l'autre du programme,


ç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).

tu tombes sur un cas ou celui-ci est
converti en pointeur, et c'est le pointeur que tu ballades.


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.


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.



Avatar
candide

Tu manques furieusement d'imagination.

Joue avec ton compilateur.



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 ...



Regarde le code machine qui resulte de
char a[] = "bonjour";
char *b = "bonjour";

tandis que dans le cas du tableau, t'as juste
une etiquette qui traine sur le premier element du tableau.


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.



tableaux, et des pointeurs. En dehors des definitions de tableaux, celles
qui reservent reellement de la place, tout le reste n'est que pointeur.


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".


Sinon, je t'emmerde mon petit gars. Et si t'es pas content, c'est pareil.


On le sentait venir.


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.


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 ?

Avatar
Francois
Merci pour vos réponses,

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
Avatar
Jean-Marc Bourguet
Francois writes:

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* :


sizeof tab vaut 10*sizeof(int)
&tab a pour type "pointeur vers tableau de 10 int"

Dans les autres contextes, il y a une conversion implicite qui fait "tout
se passe comme si" tu avais écrit &tab[0].

Et ce qui se passe pour tab se passe aussi pour les autres expressions qui
ont un type tableau, par exemple si on a déclaré

int (*pt)[10];
int t2[10][10];

alors *pt et t2[2] sont deux expressions ayant le même type que tab. On a
aussi

sizeof *pt == sizeof t2[2] == sizeof tab
&*pt, &t2[2] ont pour type "pointeur vers tableau de 10 int"

Dans les autres contextes, il y a une conversion implicite qui fait "tout
se passe comme si" tu avais écrit &(*pt)[0] ou &t2[2].

tab = tab + 1 ;


tu ne peux pas faire cela pas plus que tu ne peux faire
&tab[0] = &tab[0] + 1 ou x+1 = x+3.

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Avatar
Francois
sizeof tab vaut 10*sizeof(int)
&tab a pour type "pointeur vers tableau de 10 int"


Ce sont ce qu'on pourrait appeler des exceptions, c'est ça ?

Dans les autres contextes, ...


En dehors de ces exceptions, si je comprends bien...

... il y a une conversion implicite qui fait "tout
se passe comme si" tu avais écrit &tab[0].


ce qui revient exactement à ce que j'ai dit (adresse du premier élément
du tableau = &tab[0]), non ?

Mises à part les exceptions dont vous avez parlé (auxquelles je n'avais
effectivement pas pensé du tout, merci pour la rectification), j'ai
l'impression que j'ai dit la même chose que vous, non ?

Et ce qui se passe pour tab se passe aussi pour les autres expressions qui
ont un type tableau, par exemple si on a déclaré

int (*pt)[10];
int t2[10][10];

alors *pt et t2[2] sont deux expressions ayant le même type que tab. On a
aussi

sizeof *pt == sizeof t2[2] == sizeof tab
&*pt, &t2[2] ont pour type "pointeur vers tableau de 10 int"

Dans les autres contextes, il y a une conversion implicite qui fait "tout
se passe comme si" tu avais écrit &(*pt)[0] ou &t2[2].


Alors là vous me parlez de tableaux que je qualifierais "d'exotiques".
Dans ce que j'avais dit, je m'étais prudemment restreint à un brave "int
tab[10];". Nous parlons donc d'autres choses, non sans rapport bien sûr
et très intéressant. Et là par contre, je ne sais que dire.

Ne serait-ce pas plutôt « int t2[2][10]; » au début pour la déclaration
du tableau ?

tab = tab + 1 ;


tu ne peux pas faire cela pas plus que tu ne peux faire
&tab[0] = &tab[0] + 1 ou x+1 = x+3.


Là aussi, j'ai l'impression (peut-être à tort) que vous chercher à
rectifier une erreur de ma part. Mais encore une fois, je suis d'accord
avec vous. J'avais écrit ceci :

« tab = tab + 1 ;

n'est pas correct »

Donc nous sommes d'accord aussi là dessus, non ?


Pour résumer, j'ai l'impression étrange que :

- d'un côté, vous n'êtes pas d'accord avec mes « *tout se passe comme
si* » énoncés dans mon dernier message

- mais d'un autre côté, mises à part les exceptions (sizeof...), vous
donnez des réponses qui coïncident avec mes « *tout se passe comme si* ».

Donc, je suis un peu perplexe. En fait, je n'ai pas compris si vous
étiez d'accord avec moi. :-))


En tout cas, merci pour votre réponse.


François


Avatar
espie
In article <47dbbed1$0$22860$,
candide wrote:

Tu manques furieusement d'imagination.

Joue avec ton compilateur.



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 ...


Manque de bol, tu ne peux pas comprendre certains points de la norme
sans te plonger dans l'implementation...

Faudrait savoir, d'un cote tu veux des trucs pratiques et concrets.
Et de l'autre cote, tu refuses les trucs en question.

Chemin faisant, tu refuses une bonne partie de la philosophie du C.
C'est d'abord un langage pratique, implemente sur une classe specifique
d'architectures machines, et normalise ensuite. La normalisation a essaye
d'abstraire un maximum de details, mais il y a plein d'endroits ou on
voit l'implementation `classique' sous-jacente, et ou tres, tres peu
(voire aucune) implementation ne s'ecarte de la norme.


Regarde le code machine qui resulte de
char a[] = "bonjour";
char *b = "bonjour";

tandis que dans le cas du tableau, t'as juste
une etiquette qui traine sur le premier element du tableau.


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.


Non, en l'occurrence, c'est la trace du nom de l'objet. Ca n'est pas plus
une trace en memoire qu'un nom de fonction.

En particulier, dans char a[] = "bonjour"; a est une constante.
Encore une fois, compare avec char *b = "bonjour"; tu y trouveras un
espace memoire reserve de plus, pour stocker le pointeur b.

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.


Tu confonds l'objet lui-meme (le tableau a) et son contenu (les caracteres
qui constituent "bonjour")...

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.


Contrairement a ce que tu penses, je sais tres bien de quoi je parle.

Je ne prend pas forcement le temps de construire des reponses extremement
precises, ne serait-ce que parce que je n'ai pas forcement ma norme sous
la main (et c'est le seul document qui decrit reellement les choses, au
bout du compte).

La, pour une fois, je vais etre gentil.

Les tableaux sont decrits dans 6.2.5.20 (definition des types tableaux),
dans 6.3.2.1 (ou les exceptions a la conversion en pointeur sont specifiees:
precisement, sizeof, & unaire, et chaine literale d'initialisation), en
6.7.5.2 (declaration des tableaux), et en 6.7.8 (expressions d'initialisation).

De tous ces paragraphes, on peut deduire qu'une implementation n'a pas
besoin de stocker un objet `tableau' en memoire, juste la valeur des
elements constituants. C'est ce qu'on verifie en pratique sur toutes
les implementations pas trop neuneu du langage (notion de `qualite de
l'implementation).

Si au lieu de jouer au plus con, lorsqu'on te dit d'essayer un truc,
tu l'essayais reellement, tu aurais peut-etre plus de chance d'y voir
plus clair...


Avatar
Jean-Marc Bourguet
Francois writes:

sizeof tab vaut 10*sizeof(int)
&tab a pour type "pointeur vers tableau de 10 int"


Ce sont ce qu'on pourrait appeler des exceptions, c'est ça ?

Dans les autres contextes, ...


En dehors de ces exceptions, si je comprends bien...


L'esprit de la règle c'est "Dans les contextes qui ne peuvent pas prendre
un tableau, celui-ci est converti implicitement en un pointeur vers son
premier élément. Il y a deux contextes qui admettent un argument tableau:
sizeof et &." Elle a le même esprit que d'autres règles ("Dans un contexte
qui ne peut pas prendre un entier, celui-ci peut être transformé
implicitement en un long ou un double.")

Conserver les règles sous un même format me semble plus simple. De plus un
problème à transformer une règle en quelque chose d'apparemment équivalent,
c'est le "apparemment" : l'expérience a montré qu'on se gourre trop souvent
-- par exemple pour ce que tu as qualifié de "tableaux exotiques" ou pour
le comportement de membres tableau dans des structures -- qu'on passe alors
son temps à ajouter des cas particuliers et des exceptions et qu'on final
on a quelque chose de beaucoup plus complexe que la règle de départ et qui
ne fait qu'en approcher les conséquences.

Ta formulation est très proche de la manière dont les langages ancêtres du
C étaient définis et ce n'est donc pas étonnant que le C fonctionne aussi
presque comme ça.

Dans les autres contextes, il y a une conversion implicite qui fait "tout
se passe comme si" tu avais écrit &(*pt)[0] ou &t2[2].


Alors là vous me parlez de tableaux que je qualifierais "d'exotiques".


Quel importance? Tu me semble attacher trop d'importance à la manière dont
tu obtiens un tableau. Que ce soit le contenu d'une variable ou par une
expression compliquée, cela ne change rien.

Dans ce que j'avais dit, je m'étais prudemment restreint à un brave "int
tab[10];". Nous parlons donc d'autres choses, non sans rapport bien sûr
et très intéressant. Et là par contre, je ne sais que dire.

Ne serait-ce pas plutôt « int t2[2][10]; » au début pour la déclaration du
tableau ?


Non. La première taille peut être n'importe quoi de supérieur à 2 sans
rien changer à ce que j'ai écrit, mais pas inférieur ou égal à 2.

tab = tab + 1 ;
tu ne peux pas faire cela pas plus que tu ne peux faire &tab[0] = &tab[0]

+ 1 ou x+1 = x+3.


Là aussi, j'ai l'impression (peut-être à tort) que vous chercher à
rectifier une erreur de ma part.


Tu donnes l'impression de croire qu'il y a quelque chose de particulier
pour les variables de type tableau (voir le sujet du fil). Il y a quelque
chose de particulier pour les expressions de type tableau (la plupart du
temps elles se prennent une conversion implicite dans les pattes), mais
rien de plus pour les variables.

A+

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org



Avatar
candide

Manque de bol, tu ne peux pas comprendre certains points de la norme
sans te plonger dans l'implementation...


Sans doute lorsqu'on veut aller au-delà des mentions "implementation
defined" qu'on trouve dans la norme.

Néanmoins ton assertion est discutable et comme je n'ai pas le
background pour me lancer dans un échange intéressant là-dessus, on va
en rester là.


En particulier, dans char a[] = "bonjour"; a est une constante.


Non pour moi a est un tableau de caractères initialisé par une chaine
constante.


Encore une fois, compare avec char *b = "bonjour"; tu y trouveras un
espace memoire reserve de plus, pour stocker le pointeur b.



OK je commence à comprendre ce que tu veux dire, à savoir que la déclaration

int toto[5];

réserve de l'espace pour 5 entiers mais qu'elle n'entraîne pas de
réservation d'espace pour toto lui-même bien que l'objet toto existe, ce
que je sais bien d'ailleurs.


Tu confonds l'objet lui-meme (le tableau a) et son contenu (les caracteres
qui constituent "bonjour")...



OK. Remarque bien que la norme ne définit ce qu'est un tableau mais
seulement le _type_ tableau. Et elle ne dit pas ce qu'_est_ un type
tableau, elle dit ce que le type _décrit_.

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.


Contrairement a ce que tu penses, je sais tres bien de quoi je parle.


J'espère bien ;)


La, pour une fois, je vais etre gentil.

Les tableaux sont decrits dans 6.2.5.20 (definition des types tableaux),
dans 6.3.2.1 (ou les exceptions a la conversion en pointeur sont specifiees:
precisement, sizeof, & unaire, et chaine literale d'initialisation), en
6.7.5.2 (declaration des tableaux), et en 6.7.8 (expressions d'initialisation).


Tu es en effet très gentil mais j'ai lu la norme C90 une fois (en fait
pas la clause library) donc je sais quand même où cjercjer l'info à
défaut de la comprendre vraiment. Et avant de répondre, j'ai cherché
toutes les occurrences du mot "array" dans la norme et j'ai regardé une
par une.


De tous ces paragraphes, on peut deduire qu'une implementation n'a pas
besoin de stocker un objet `tableau' en memoire, juste la valeur des
elements constituants.


D'accord mais alors comment l'implémentation fait-elle pour convertir
implicitement un tableau en pointeur, faut bien qu'elle trouve l'adresse
quelque part ? C'était ça le sens de ma réponse à la question de
François (que j'avais peut-être mal comprise).


Si au lieu de jouer au plus con,


Cool man

lorsqu'on te dit d'essayer un truc,
tu l'essayais reellement, tu aurais peut-etre plus de chance d'y voir
plus clair...


Oui, tu m'as dit d'essayer quel truc _précisément_ ("jouer avec son
compilateur" est une mauvaise réponse) ?


1 2 3 4 5