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.
Pour etre clair: les parentheses en question sont celles utilisees pour grouper, pas pour les fonctions.
On part du nom declare, on va en avant jusqu'a la fin ou une parenthese fermante, puis en arriere jusqu'au debut ou une parenthese ouvrante, etc.
Merci beaucoup :-)
François
YBM
Tsss tsss... tu ne l'as vraiment pas lue...
Effectivement
En rapport avec l'inadéquation du contenu de ton message, je n'ose pas imaginer la qualité d'une documentation sur le C écrite par toi.
... vraiment pas lue. Où peut-être que le concept principal de cette FAQ
Vous avez dit "concept" ?
sigh...
5.3: So what is meant by the ``equivalence of pointers and arrays'' in C?
Very little. 5.4: Then why are array and pointer declarations interchangeable as function formal parameters?
Classism. We consider arrays ``second class objects''. They don't vote, and they get treated as pointers. Additionally, they're merely objects, not citizens. Marx wrote about this a lot.
(from : http://www.seebs.net/faqs/c-iaq.html )
Tsss tsss... tu ne l'as vraiment pas lue...
Effectivement
En rapport avec l'inadéquation du contenu de ton message, je n'ose
pas imaginer la qualité d'une documentation sur le C écrite par toi.
... vraiment pas lue. Où peut-être que le concept principal de cette FAQ
Vous avez dit "concept" ?
sigh...
5.3: So what is meant by the ``equivalence of pointers and arrays'' in C?
Very little.
5.4: Then why are array and pointer declarations interchangeable as
function formal parameters?
Classism. We consider arrays ``second class objects''. They don't vote,
and they get treated as pointers. Additionally, they're merely objects,
not citizens. Marx wrote about this a lot.
En rapport avec l'inadéquation du contenu de ton message, je n'ose pas imaginer la qualité d'une documentation sur le C écrite par toi.
... vraiment pas lue. Où peut-être que le concept principal de cette FAQ
Vous avez dit "concept" ?
sigh...
5.3: So what is meant by the ``equivalence of pointers and arrays'' in C?
Very little. 5.4: Then why are array and pointer declarations interchangeable as function formal parameters?
Classism. We consider arrays ``second class objects''. They don't vote, and they get treated as pointers. Additionally, they're merely objects, not citizens. Marx wrote about this a lot.
(from : http://www.seebs.net/faqs/c-iaq.html )
candide
Rassure-moi, on peut quand même faire honnêtement du C sans savoir comment marche un compilateur, y compris l'ignorer dans les grandes lignes ?
Oui. Mais alors il faut abandonner l'idee de comprendre le pourquoi des regles. Et tu auras beaucoup plus de mal a les apprendre.
Je pense que ça se discute : je comprends assez bien le français, je l'écris à peu près correctement, je suis sensible au choix des mots, je peux faire des analogies avec d'autres langues et pourtant je n'ai jamais rien entravé au latin ni à l'ancien français, je garde par exemple des souvenirs cauchemardesques des /Essais/ de Montaigne en version originale et je fais une aversion au jargon linguistique qu'utilisent les instits pour enseigner le français à nos enfants. Et je pense que ma position n'a rien de marginal. Bien sûr, on pourra toujours contester la validité de ce genre de parallèle et pourtant il me semble justement s'appliquer d'autant plus que la complexité d'un langage naturel supplante largement celle d'un langage de programmation "artificiel".
À vrai dire, le pourquoi des règles a souvent une origine historique, d'ailleurs ça m'amuse ces ouvrages qui commencent leur exposé du langage par l'inévitable historique, comme si ça en faisait partie. Ne prenez pas mal mon discours, je sais qu'il existe sur ce forum des spécialistes de l'évolution du langage, je suis bien conscient que ça apporte un plus à la compréhension du langage, je respecte leur savoir mais je suis convaincu qu'un _utilisateur_ débutant voire avancé peut se dispenser de ce genre de savoir.
Rassure-moi, on peut quand même faire honnêtement du C sans savoir comment
marche un compilateur, y compris l'ignorer dans les grandes lignes ?
Oui. Mais alors il faut abandonner l'idee de comprendre le pourquoi des
regles. Et tu auras beaucoup plus de mal a les apprendre.
Je pense que ça se discute : je comprends assez bien le français, je
l'écris à peu près correctement, je suis sensible au choix des mots, je
peux faire des analogies avec d'autres langues et pourtant je n'ai
jamais rien entravé au latin ni à l'ancien français, je garde par
exemple des souvenirs cauchemardesques des /Essais/ de Montaigne en
version originale et je fais une aversion au jargon linguistique
qu'utilisent les instits pour enseigner le français à nos enfants. Et je
pense que ma position n'a rien de marginal. Bien sûr, on pourra toujours
contester la validité de ce genre de parallèle et pourtant il me semble
justement s'appliquer d'autant plus que la complexité d'un langage
naturel supplante largement celle d'un langage de programmation
"artificiel".
À vrai dire, le pourquoi des règles a souvent une origine historique,
d'ailleurs ça m'amuse ces ouvrages qui commencent leur exposé du langage
par l'inévitable historique, comme si ça en faisait partie. Ne prenez
pas mal mon discours, je sais qu'il existe sur ce forum des spécialistes
de l'évolution du langage, je suis bien conscient que ça apporte un plus
à la compréhension du langage, je respecte leur savoir mais je suis
convaincu qu'un _utilisateur_ débutant voire avancé peut se dispenser de
ce genre de savoir.
Rassure-moi, on peut quand même faire honnêtement du C sans savoir comment marche un compilateur, y compris l'ignorer dans les grandes lignes ?
Oui. Mais alors il faut abandonner l'idee de comprendre le pourquoi des regles. Et tu auras beaucoup plus de mal a les apprendre.
Je pense que ça se discute : je comprends assez bien le français, je l'écris à peu près correctement, je suis sensible au choix des mots, je peux faire des analogies avec d'autres langues et pourtant je n'ai jamais rien entravé au latin ni à l'ancien français, je garde par exemple des souvenirs cauchemardesques des /Essais/ de Montaigne en version originale et je fais une aversion au jargon linguistique qu'utilisent les instits pour enseigner le français à nos enfants. Et je pense que ma position n'a rien de marginal. Bien sûr, on pourra toujours contester la validité de ce genre de parallèle et pourtant il me semble justement s'appliquer d'autant plus que la complexité d'un langage naturel supplante largement celle d'un langage de programmation "artificiel".
À vrai dire, le pourquoi des règles a souvent une origine historique, d'ailleurs ça m'amuse ces ouvrages qui commencent leur exposé du langage par l'inévitable historique, comme si ça en faisait partie. Ne prenez pas mal mon discours, je sais qu'il existe sur ce forum des spécialistes de l'évolution du langage, je suis bien conscient que ça apporte un plus à la compréhension du langage, je respecte leur savoir mais je suis convaincu qu'un _utilisateur_ débutant voire avancé peut se dispenser de ce genre de savoir.
candide
J'ai un peu de mal avec les déclarations de pointeurs.
Il y a de quoi.
Il existe traditionnellement deux méthodes pour déchiffer les déclarations C : la méthode méthode bottom-up (celle qu'évoque JMB),et la top-down que personnellement je préfère.
Quelques références concernant méthode bottom-up :
*) The "right-left" rule : http://ieng9.ucsd.edu/~cs30x/rt_lt.rule.html
Je n'ai pas de référence pour l'autre méthode, je ne sais plus où je l'ai apprise, dans le bouquin de Delannoy je crois, /La référence du C norme ANSI/.
Il faut aussi que tu installes un programme amusant et utile quand on apprend le C : cdecl, ça sert à déchiffrer des déclarations. Utilise apt-get pour l'installer puis en console tape cdecl puis, à l'invite, tape explain puis écris ta déclaration (romantique !), exemple :
:~$ cdecl Type `help' or `?' for help cdecl> explain int *p[10] declare p as array 10 of pointer to int cdecl> explain int *(**p)[10][12] declare p as pointer to pointer to array 10 of array 12 of pointer to int cdecl>
J'ai un peu de
mal avec les déclarations de pointeurs.
Il y a de quoi.
Il existe traditionnellement deux méthodes pour déchiffer les
déclarations C : la méthode méthode bottom-up (celle qu'évoque JMB),et
la top-down que personnellement je préfère.
Quelques références concernant méthode bottom-up :
*) The "right-left" rule :
http://ieng9.ucsd.edu/~cs30x/rt_lt.rule.html
Je n'ai pas de référence pour l'autre méthode, je ne sais plus où je
l'ai apprise, dans le bouquin de Delannoy je crois,
/La référence du C norme ANSI/.
Il faut aussi que tu installes un programme amusant et utile quand on
apprend le C : cdecl, ça sert à déchiffrer des déclarations. Utilise
apt-get pour l'installer puis en console tape cdecl
puis, à l'invite, tape explain puis écris ta déclaration (romantique !),
exemple :
candide@candide-desktop:~$ cdecl
Type `help' or `?' for help
cdecl> explain int *p[10]
declare p as array 10 of pointer to int
cdecl> explain int *(**p)[10][12]
declare p as pointer to pointer to array 10 of array 12 of pointer to int
cdecl>
J'ai un peu de mal avec les déclarations de pointeurs.
Il y a de quoi.
Il existe traditionnellement deux méthodes pour déchiffer les déclarations C : la méthode méthode bottom-up (celle qu'évoque JMB),et la top-down que personnellement je préfère.
Quelques références concernant méthode bottom-up :
*) The "right-left" rule : http://ieng9.ucsd.edu/~cs30x/rt_lt.rule.html
Je n'ai pas de référence pour l'autre méthode, je ne sais plus où je l'ai apprise, dans le bouquin de Delannoy je crois, /La référence du C norme ANSI/.
Il faut aussi que tu installes un programme amusant et utile quand on apprend le C : cdecl, ça sert à déchiffrer des déclarations. Utilise apt-get pour l'installer puis en console tape cdecl puis, à l'invite, tape explain puis écris ta déclaration (romantique !), exemple :
:~$ cdecl Type `help' or `?' for help cdecl> explain int *p[10] declare p as array 10 of pointer to int cdecl> explain int *(**p)[10][12] declare p as pointer to pointer to array 10 of array 12 of pointer to int cdecl>
candide
Il faut aussi que tu installes un programme amusant et utile quand on apprend le C : cdecl, ça sert à déchiffrer des déclarations. Utilise apt-get pour l'installer
Il faut aussi que tu installes un programme amusant et utile quand on
apprend le C : cdecl, ça sert à déchiffrer des déclarations. Utilise
apt-get pour l'installer
Il faut aussi que tu installes un programme amusant et utile quand on apprend le C : cdecl, ça sert à déchiffrer des déclarations. Utilise apt-get pour l'installer
Il faut aussi que tu installes un programme amusant...
C'est marrant ce truc. Merci pour les références et pour le programme "cdecl". C'est incroyable le nombre de petits programmes "amusants" qu'il y a sur Linux. Tout à l'heure, quelqu'un a évoqué un programme nommé "indent" pour indenter du code. Ca marche impeccable ce truc, j'ai testé sur un code non indenté, c'est surprenant.
Petite question : Sur ton premier lien, je vois "int (*fpf())();". Ca existe des truc comme ça dans "la vraie vie" ?
Autre question : Quand tu parlais de livre "La référence du C norme ANSI-ISO" de Delannoy, je me demandais si ce livre là
"Langage C" de Delannoy Editeur : Eyrolles (29 août 2002) Collection : Best Of ISBN-10: 2212111231 http://www.amazon.fr/Langage-C-Claude-Delannoy/dp/2212111231/ref=sr_1_5?ie=UTF8&s=books&qid05966056&sr=1-5
en était une réédition plus récente. On dirait que oui, mais le titre n'est pas exactement le même et en plus il est moins cher que "La référence du C norme ANSI-ISO" (bien que plus récent!).
François
Il faut aussi que tu installes un programme amusant...
C'est marrant ce truc. Merci pour les références et pour le programme
"cdecl". C'est incroyable le nombre de petits programmes "amusants"
qu'il y a sur Linux. Tout à l'heure, quelqu'un a évoqué un programme
nommé "indent" pour indenter du code. Ca marche impeccable ce truc, j'ai
testé sur un code non indenté, c'est surprenant.
Petite question :
Sur ton premier lien, je vois "int (*fpf())();". Ca existe des truc
comme ça dans "la vraie vie" ?
Autre question :
Quand tu parlais de livre "La référence du C norme ANSI-ISO" de
Delannoy, je me demandais si ce livre là
"Langage C" de Delannoy
Editeur : Eyrolles (29 août 2002)
Collection : Best Of
ISBN-10: 2212111231
http://www.amazon.fr/Langage-C-Claude-Delannoy/dp/2212111231/ref=sr_1_5?ie=UTF8&s=books&qid05966056&sr=1-5
en était une réédition plus récente. On dirait que oui, mais le titre
n'est pas exactement le même et en plus il est moins cher que "La
référence du C norme ANSI-ISO" (bien que plus récent!).
Il faut aussi que tu installes un programme amusant...
C'est marrant ce truc. Merci pour les références et pour le programme "cdecl". C'est incroyable le nombre de petits programmes "amusants" qu'il y a sur Linux. Tout à l'heure, quelqu'un a évoqué un programme nommé "indent" pour indenter du code. Ca marche impeccable ce truc, j'ai testé sur un code non indenté, c'est surprenant.
Petite question : Sur ton premier lien, je vois "int (*fpf())();". Ca existe des truc comme ça dans "la vraie vie" ?
Autre question : Quand tu parlais de livre "La référence du C norme ANSI-ISO" de Delannoy, je me demandais si ce livre là
"Langage C" de Delannoy Editeur : Eyrolles (29 août 2002) Collection : Best Of ISBN-10: 2212111231 http://www.amazon.fr/Langage-C-Claude-Delannoy/dp/2212111231/ref=sr_1_5?ie=UTF8&s=books&qid05966056&sr=1-5
en était une réédition plus récente. On dirait que oui, mais le titre n'est pas exactement le même et en plus il est moins cher que "La référence du C norme ANSI-ISO" (bien que plus récent!).
