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.
Je pense qu'on ne peut pas s'affranchir de certains points d'organisation mémoire, et que certaines connaissances sur les pb d'alignement permettent de "mieux" intégrer les restrictions imposées par la norme.
J'irais même un peu plus loin. Il me semble qu'il est préférable, c'est le minimum même si ce n'est pas absolument obligatoire, que rien ne paraisse "magique" au programmeur. Mais à partir du moment où il sent qu'une chose est normalement possible, il peut faire l'économie, selon le niveau de son travail, de savoir dans les détails comment elle est menée à bien(*). Par exemple il me paraît difficile de coder efficacement en C si on n'a pas une fois compris que l'adresse d'un objet (tableau ou autre) est en définitive une constante littérale, c'est à dire qu'on va "souvent" la retrouver en dur dans le code exécutable. C'est strictement la même chose en assembleur, et ce n'est pas non plus immédiat à piger.
(*) Quand on est amené à chercher à comprendre comment ça se passe, c'est souvent que la documentation du produit utilisé est insuffisante, ou qu'on n'a pas su y trouver ce qu'il faut.
-- Pierre Maurette
[...]
Je ne sais pas.
Je pense qu'on ne peut pas s'affranchir de certains points
d'organisation mémoire, et que certaines connaissances sur
les pb d'alignement permettent de "mieux" intégrer les
restrictions imposées par la norme.
J'irais même un peu plus loin. Il me semble qu'il est préférable, c'est
le minimum même si ce n'est pas absolument obligatoire, que rien ne
paraisse "magique" au programmeur.
Mais à partir du moment où il sent qu'une chose est normalement
possible, il peut faire l'économie, selon le niveau de son travail, de
savoir dans les détails comment elle est menée à bien(*).
Par exemple il me paraît difficile de coder efficacement en C si on n'a
pas une fois compris que l'adresse d'un objet (tableau ou autre) est en
définitive une constante littérale, c'est à dire qu'on va "souvent" la
retrouver en dur dans le code exécutable. C'est strictement la même
chose en assembleur, et ce n'est pas non plus immédiat à piger.
(*) Quand on est amené à chercher à comprendre comment ça se passe,
c'est souvent que la documentation du produit utilisé est insuffisante,
ou qu'on n'a pas su y trouver ce qu'il faut.
Je pense qu'on ne peut pas s'affranchir de certains points d'organisation mémoire, et que certaines connaissances sur les pb d'alignement permettent de "mieux" intégrer les restrictions imposées par la norme.
J'irais même un peu plus loin. Il me semble qu'il est préférable, c'est le minimum même si ce n'est pas absolument obligatoire, que rien ne paraisse "magique" au programmeur. Mais à partir du moment où il sent qu'une chose est normalement possible, il peut faire l'économie, selon le niveau de son travail, de savoir dans les détails comment elle est menée à bien(*). Par exemple il me paraît difficile de coder efficacement en C si on n'a pas une fois compris que l'adresse d'un objet (tableau ou autre) est en définitive une constante littérale, c'est à dire qu'on va "souvent" la retrouver en dur dans le code exécutable. C'est strictement la même chose en assembleur, et ce n'est pas non plus immédiat à piger.
(*) Quand on est amené à chercher à comprendre comment ça se passe, c'est souvent que la documentation du produit utilisé est insuffisante, ou qu'on n'a pas su y trouver ce qu'il faut.
