Chercher un livre sur le C avec certains critères.
200 réponses
Francois
Bonjour à tous,
Je débute dans le C et personnellement j'apprends surtout avec les
livres. J'ai commencé "Livre du C premier langage" de Delannoy (je
précise que j'avais quand même des petites notions de programmations,
même si, à mon sens, j'étais [ et suis encore ? ] vraiment ce qu'on
appelle un débutant).
Je suis en train de lire le K&R (deuxième édition) qui est bien sûr
beaucoup plus difficile. C'est du concentré, mais quand on y regarde de
prêt, c'est quand assez précis et bien fait. Ceci étant, il y a des
choses qui ne me satisfont pas complètement.
Je trouve que ce livre à une approche trop éloignée de la machine
(comment une donnée est encodée ? comment se passe l'histoire du signed
ou unsigned du point de vue de la machine etc.). Je m'explique.
Bien sûr, le langage C est un langage abstrait de "haut niveau" qui se
doit (en principe) de ne pas faire référence à la machine. Donc c'est
normal qu'un livre sur le C ne parle pas (trop) des problèmes qui
dépendent de l'architecture. Ceci étant, j'aimerais savoir si un tel
livre existe malgré tout. Un livre qui expose le langage C et qui
n'hésite pas de temps en temps à parler de ce qui se passe dans la
machine (bien sûr, justement, ce qui se passe dépend de la machine et
n'est pas universel, mais le livre pourrait présenter les choses sur
seulement une architecture "classique" par exemple). Bon, si je pouvais
éviter les circuits électroniques et compagnie quand même, ça serait
bien. Qu'on me dise que "le complément à 2 fait que l'addition devient
plus simple pour l'ordinateur puisqu'il suffit de faire une addition
classique" me suffit amplement. Une preuve de cela en passant des
explications sur des circuits électroniques peut-être me serait un peu
indigeste.
Bref, j'espère avoir été clair sur cette sorte de compromis que je
recherche (existe-t-il ?). Vous pouvez aller voir cette discussion (où
mon pseudo est sisco)
Donc K&R ne définit même pas les termes qu'il utilise, on découvre les notions par hasard et dans un autre contexte où on est préoccupé par autre chose. Naturellement, une bibliothèque est pour eux une abstraction, on ne dira jamais qu'une bibliothèque est un fichier archive, on ne parlera pas de bibliothèques dynamiques (ça existait à l'époque) alors que c'est le pain quotidien du programmeur. Donc c'est bien ce que je dis, le C du K&R est non tangible. C comme Concept.
Ca ne rentre PAS dans le plan du bouquin. Le K&R decrit le langage C, et fait tres, tres gaffe a ne pas rentrer dans les details propres a un OS ou une implementation donnee. Il est tres clair dans le bouquin que tu es cense trouver des infos ailleurs, concernant bibliotheques et outils de compilation.
Ca n'est pas un bouquin de debutant en developpement. Juste un bouquin de presentation du langage, complet et tres accessible si tu connais deja un peu d'informatique.
In article <b4bcc53d-3f62-4365-b1c3-0c0f96c4cefe@n36g2000hse.googlegroups.com>,
candide <c-candide@wanadoo.fr> wrote:
Donc K&R ne définit même pas les termes qu'il utilise, on découvre les
notions par hasard et dans un autre contexte où on est préoccupé par
autre chose. Naturellement, une bibliothèque est pour eux une
abstraction, on ne dira jamais qu'une bibliothèque est un fichier
archive, on ne parlera pas de bibliothèques dynamiques (ça existait à
l'époque) alors que c'est le pain quotidien du programmeur. Donc c'est
bien ce que je dis, le C du K&R est non tangible. C comme Concept.
Ca ne rentre PAS dans le plan du bouquin. Le K&R decrit le langage C,
et fait tres, tres gaffe a ne pas rentrer dans les details propres a un
OS ou une implementation donnee. Il est tres clair dans le bouquin que
tu es cense trouver des infos ailleurs, concernant bibliotheques et
outils de compilation.
Ca n'est pas un bouquin de debutant en developpement. Juste un bouquin
de presentation du langage, complet et tres accessible si tu connais
deja un peu d'informatique.
Donc K&R ne définit même pas les termes qu'il utilise, on découvre les notions par hasard et dans un autre contexte où on est préoccupé par autre chose. Naturellement, une bibliothèque est pour eux une abstraction, on ne dira jamais qu'une bibliothèque est un fichier archive, on ne parlera pas de bibliothèques dynamiques (ça existait à l'époque) alors que c'est le pain quotidien du programmeur. Donc c'est bien ce que je dis, le C du K&R est non tangible. C comme Concept.
Ca ne rentre PAS dans le plan du bouquin. Le K&R decrit le langage C, et fait tres, tres gaffe a ne pas rentrer dans les details propres a un OS ou une implementation donnee. Il est tres clair dans le bouquin que tu es cense trouver des infos ailleurs, concernant bibliotheques et outils de compilation.
Ca n'est pas un bouquin de debutant en developpement. Juste un bouquin de presentation du langage, complet et tres accessible si tu connais deja un peu d'informatique.
candide
On 9 mar, 19:20, Francois wrote:
Pourrais-tu donner des références PRÉCISES dans K&R, voire citer le texte original.
1) "Un nom de tableau n'est pas une variable ; donc des instructions telles que a = pa et a++ [où a est un tableau] sont incorrectes.]"
Où ?
2) "le *nom* d'un tableau est synonyme de l'adresse de son élément ini tial".
Synonyme ??? Où ?
3) "Par définition, la valeur d'une variable ou d'une expression de type tableau est l'adresse de l'élément 0 du tableau"
OK, §5.3
Pour moi 3) semble dire qu'on puisse parle de variable tableau ce que contredit clairement 1). Est-il possible d'avoir une explication ?
De toute façon, K&R parle de "variable" sans jamais définir ce que c'est, comme ça on peut tout et rien comprendre. Est-ce que pour eux une variable est un objet, une variable peut-elle être une fonction ? Est-ce que pour eux une variable c'est une lvalue ? une lvalue modifiable ? mystère.
Je viens de relire le §1.6 sur les tableaux : mais quelle horreur ! tout est basé sur un programme hyper-surchargé avec des conversions partout, ils se perdent dans des trucs qui n'ont aucun rapport avec les tableaux (des considérations sur les caractères qu'ont apprend au détour d'une phrase qu'en fait ce sont de petits nombres (1) et ensuite toute la fin qui est consacrée à des instructions conditionnelles if else et switch), bref ils font un § sur les tableaux et ils parlent à peine de tableau, voilà en résumé toute la pédagogie du K&R.
(1) c'est typique du brouillon K&R : on vous explique au détour d'une phrase via un DÉTAIL quelque chose d'hyper important qui mériterait un développement à lui tout seul. Le coup des caractère est assez typique.
On 9 mar, 19:20, Francois <mathsatta...@free.fr> wrote:
Pourrais-tu donner des références PRÉCISES dans K&R, voire citer le
texte original.
1) "Un nom de tableau n'est pas une variable ; donc des instructions
telles que a = pa et a++ [où a est un tableau] sont incorrectes.]"
Où ?
2) "le *nom* d'un tableau est synonyme de l'adresse de son élément ini tial".
Synonyme ??? Où ?
3) "Par définition, la valeur d'une variable ou d'une expression de type
tableau est l'adresse de l'élément 0 du tableau"
OK, §5.3
Pour moi 3) semble dire qu'on puisse parle de variable tableau ce que
contredit clairement 1). Est-il possible d'avoir une explication ?
De toute façon, K&R parle de "variable" sans jamais définir ce que
c'est, comme ça on peut tout et rien comprendre. Est-ce que pour eux
une variable est un objet, une variable peut-elle être une fonction ?
Est-ce que pour eux une variable c'est une lvalue ? une lvalue
modifiable ? mystère.
Je viens de relire le §1.6 sur les tableaux : mais quelle horreur !
tout est basé sur un programme hyper-surchargé avec des conversions
partout, ils se perdent dans des trucs qui n'ont aucun rapport avec
les tableaux (des considérations sur les caractères qu'ont apprend au
détour d'une phrase qu'en fait ce sont de petits nombres (1) et
ensuite toute la fin qui est consacrée à des instructions
conditionnelles if else et switch), bref ils font un § sur les
tableaux et ils parlent à peine de tableau, voilà en résumé toute la
pédagogie du K&R.
(1) c'est typique du brouillon K&R : on vous explique au détour d'une
phrase via un DÉTAIL quelque chose d'hyper important qui mériterait un
développement à lui tout seul. Le coup des caractère est assez
typique.
Pourrais-tu donner des références PRÉCISES dans K&R, voire citer le texte original.
1) "Un nom de tableau n'est pas une variable ; donc des instructions telles que a = pa et a++ [où a est un tableau] sont incorrectes.]"
Où ?
2) "le *nom* d'un tableau est synonyme de l'adresse de son élément ini tial".
Synonyme ??? Où ?
3) "Par définition, la valeur d'une variable ou d'une expression de type tableau est l'adresse de l'élément 0 du tableau"
OK, §5.3
Pour moi 3) semble dire qu'on puisse parle de variable tableau ce que contredit clairement 1). Est-il possible d'avoir une explication ?
De toute façon, K&R parle de "variable" sans jamais définir ce que c'est, comme ça on peut tout et rien comprendre. Est-ce que pour eux une variable est un objet, une variable peut-elle être une fonction ? Est-ce que pour eux une variable c'est une lvalue ? une lvalue modifiable ? mystère.
Je viens de relire le §1.6 sur les tableaux : mais quelle horreur ! tout est basé sur un programme hyper-surchargé avec des conversions partout, ils se perdent dans des trucs qui n'ont aucun rapport avec les tableaux (des considérations sur les caractères qu'ont apprend au détour d'une phrase qu'en fait ce sont de petits nombres (1) et ensuite toute la fin qui est consacrée à des instructions conditionnelles if else et switch), bref ils font un § sur les tableaux et ils parlent à peine de tableau, voilà en résumé toute la pédagogie du K&R.
(1) c'est typique du brouillon K&R : on vous explique au détour d'une phrase via un DÉTAIL quelque chose d'hyper important qui mériterait un développement à lui tout seul. Le coup des caractère est assez typique.
candide
On 9 mar, 20:08, (Marc Espie) wrote:
Ca ne rentre PAS dans le plan du bouquin. Le K&R decrit le langage C, et fait tres, tres gaffe a ne pas rentrer dans les details propres a un OS ou une implementation donnee.
Mauvais calcul, il ne s'agit pas à proprement parler de rentrer dans les détails d'une implémentation donnée (quoique au passage le dernier chapitre est consacré à Unix), il s'agit à travers d'un exemple de dire comment ça se passe partout, un peu comme une récurrence qui dès lors qu'elle est vraie pour n=2 est vraie pour tout n. Mais bon, concernant les bibliothèques, le compilateur, le linker etc, K&R ont des excuses, l'informatique de 1978 et de 1988 n'est pas celle d'aujourd'hui, les outils sont très accessibles maintenant. Il n'en reste pas moins qu'une bibliothèque c'est tangible et qu'avec K&R à ça reste une abstraction et qu'il leur aurait tout à fait été possible d'en parler sans se perdre dans des détails d'implémentation (il suffit de rester générique). Et ils ont même le défaut de faire mal penser le lecteur en l'autorisant presque à identifier bibliothèque et bibliothèque standard.
On 9 mar, 20:08, es...@lain.home (Marc Espie) wrote:
Ca ne rentre PAS dans le plan du bouquin. Le K&R decrit le langage C,
et fait tres, tres gaffe a ne pas rentrer dans les details propres a un
OS ou une implementation donnee.
Mauvais calcul, il ne s'agit pas à proprement parler de rentrer dans
les détails d'une implémentation donnée (quoique au passage le dernier
chapitre est consacré à Unix), il s'agit à travers d'un exemple de
dire comment ça se passe partout, un peu comme une récurrence qui dès
lors qu'elle est vraie pour n=2 est vraie pour tout n. Mais bon,
concernant les bibliothèques, le compilateur, le linker etc, K&R ont
des excuses, l'informatique de 1978 et de 1988 n'est pas celle
d'aujourd'hui, les outils sont très accessibles maintenant. Il n'en
reste pas moins qu'une bibliothèque c'est tangible et qu'avec K&R à ça
reste une abstraction et qu'il leur aurait tout à fait été possible
d'en parler sans se perdre dans des détails d'implémentation (il
suffit de rester générique). Et ils ont même le défaut de faire mal
penser le lecteur en l'autorisant presque à identifier bibliothèque
et bibliothèque standard.
Ca ne rentre PAS dans le plan du bouquin. Le K&R decrit le langage C, et fait tres, tres gaffe a ne pas rentrer dans les details propres a un OS ou une implementation donnee.
Mauvais calcul, il ne s'agit pas à proprement parler de rentrer dans les détails d'une implémentation donnée (quoique au passage le dernier chapitre est consacré à Unix), il s'agit à travers d'un exemple de dire comment ça se passe partout, un peu comme une récurrence qui dès lors qu'elle est vraie pour n=2 est vraie pour tout n. Mais bon, concernant les bibliothèques, le compilateur, le linker etc, K&R ont des excuses, l'informatique de 1978 et de 1988 n'est pas celle d'aujourd'hui, les outils sont très accessibles maintenant. Il n'en reste pas moins qu'une bibliothèque c'est tangible et qu'avec K&R à ça reste une abstraction et qu'il leur aurait tout à fait été possible d'en parler sans se perdre dans des détails d'implémentation (il suffit de rester générique). Et ils ont même le défaut de faire mal penser le lecteur en l'autorisant presque à identifier bibliothèque et bibliothèque standard.
Francois
Je viens de relire le §1.6 sur les tableaux : mais quelle horreur !
Bon, je vais me faire l'avocat du diable en disant que dans le chapitre 1, le but n'est pas d'être complet et précis, mais de faire un tour rapide. C'est dit au début du chapitre.
Par contre au chapitre 5 paragraphe 3 (sur les pointeurs et les tableaux) qui est présente les choses plus rigoureusement, j'ai des soucis. Je ne cherche pas à dire du mal de ce livre (déjà il faudrait que je lise entièrement), mais je voudrais bien comprendre, c'est tout.
Tout au début du §5.3 (peu après les dessins), il est dit :
1) "Par définition, la valeur d'une *variable* ou d'une expression de type tableau est l'adresse de l'élément 0 du tableau"
puis quelques lignes après :
"Un nom de tableau n'est pas une variable ; donc des instructions telles que a = pa et a++ [où a est un tableau] sont incorrectes.]"
ce qui me semble contradictoire. Or, ma version (je parle de la deuxième édition) est une version française. Et pour le coup, ça m'est déjà arrivé, il se peut que ce soit une erreur de traduction.
J'aimerais bien avoir l'avis de spécialistes, si possible qui possède la version anglaise.
Merci
François
Je viens de relire le §1.6 sur les tableaux : mais quelle horreur !
Bon, je vais me faire l'avocat du diable en disant que dans le chapitre
1, le but n'est pas d'être complet et précis, mais de faire un tour
rapide. C'est dit au début du chapitre.
Par contre au chapitre 5 paragraphe 3 (sur les pointeurs et les
tableaux) qui est présente les choses plus rigoureusement, j'ai des
soucis. Je ne cherche pas à dire du mal de ce livre (déjà il faudrait
que je lise entièrement), mais je voudrais bien comprendre, c'est tout.
Tout au début du §5.3 (peu après les dessins), il est dit :
1) "Par définition, la valeur d'une *variable* ou d'une expression de
type tableau est l'adresse de l'élément 0 du tableau"
puis quelques lignes après :
"Un nom de tableau n'est pas une variable ; donc des instructions telles
que a = pa et a++ [où a est un tableau] sont incorrectes.]"
ce qui me semble contradictoire. Or, ma version (je parle de la deuxième
édition) est une version française. Et pour le coup, ça m'est déjà
arrivé, il se peut que ce soit une erreur de traduction.
J'aimerais bien avoir l'avis de spécialistes, si possible qui possède la
version anglaise.
Je viens de relire le §1.6 sur les tableaux : mais quelle horreur !
Bon, je vais me faire l'avocat du diable en disant que dans le chapitre 1, le but n'est pas d'être complet et précis, mais de faire un tour rapide. C'est dit au début du chapitre.
Par contre au chapitre 5 paragraphe 3 (sur les pointeurs et les tableaux) qui est présente les choses plus rigoureusement, j'ai des soucis. Je ne cherche pas à dire du mal de ce livre (déjà il faudrait que je lise entièrement), mais je voudrais bien comprendre, c'est tout.
Tout au début du §5.3 (peu après les dessins), il est dit :
1) "Par définition, la valeur d'une *variable* ou d'une expression de type tableau est l'adresse de l'élément 0 du tableau"
puis quelques lignes après :
"Un nom de tableau n'est pas une variable ; donc des instructions telles que a = pa et a++ [où a est un tableau] sont incorrectes.]"
ce qui me semble contradictoire. Or, ma version (je parle de la deuxième édition) est une version française. Et pour le coup, ça m'est déjà arrivé, il se peut que ce soit une erreur de traduction.
J'aimerais bien avoir l'avis de spécialistes, si possible qui possède la version anglaise.
Merci
François
Jean-Marc Bourguet
Francois writes:
Un tableau et un pointeur ont des TYPES différents. Il y a des similitudes entre les deux mais aussi pas mal de différences en sorte que les utilisations ne sont pas interchangeables. Ce qui se passe, c'est que la valeur d'une variable de type tableau est l'adresse de son premier élément NON. La valeur d'une variable de type tableau est le tableau. Ce
tableau, comme tous les autres qu'ils soient des variables ou pas, est converti dans la plupart des contextes en un pointeur vers son premier élément.
En fait, si j'en crois le K&R :
1) "Un nom de tableau n'est pas une variable ; donc des instructions telles que a = pa et a++ [où a est un tableau] sont incorrectes.]"
2) "le *nom* d'un tableau est synonyme de l'adresse de son élément initial".
Jusque là, ça va pour moi. Mais il y a aussi :
3) "Par définition, la valeur d'une variable ou d'une expression de type tableau est l'adresse de l'élément 0 du tableau"
Pour moi 3) semble dire qu'on puisse parle de variable tableau ce que contredit clairement 1). Est-il possible d'avoir une explication ? (peut-être que c'est la traduction, ça m'est déjà arrivé).
Je ne peux pas faire une exégèse du K&R tant qu'on ne m'a pas rendu mon exemplaire.
Le nom n'est pas la chose qu'il désigne. Mais je doute que ce soit l'objectif de la phrase. Il faudrait peut-être plus de contexte pour l'expliquer (et peut-être comparer avec le texte anglais ou même la première édition pour voir si ce n'est pas quelque chose qui aurait dû être mieux reformulé).
Pour moi il est clair qu'on peut parler d'une variable de type tableau: il y a des objets de ce type qui sont nommés, ce qui est la définition habituelle de variable (il n'y a pas de définition dans la norme, je viens de regarder toutes les occurences de "variable").
Une lvalue de type tableau (qu'elle soit une variable ou pas) est convertie dans la plupart des contextes (exceptions: argument de sizeof et de &) en un pointeur vers son premier élément et le résultat de cette conversion n'est pas une lvalue. Donc ne peut pas être l'argument de gauche de "=" ou un argument de ++ qui doivent être des lvalues.
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
Francois <mathsattacks@free.fr> writes:
Un tableau et un pointeur ont des TYPES différents. Il y a des
similitudes entre les deux mais aussi pas mal de différences en sorte que
les utilisations ne sont pas interchangeables. Ce qui se passe, c'est
que la valeur d'une variable de type tableau est l'adresse de son premier
élément
NON. La valeur d'une variable de type tableau est le tableau. Ce
tableau,
comme tous les autres qu'ils soient des variables ou pas, est converti dans
la plupart des contextes en un pointeur vers son premier élément.
En fait, si j'en crois le K&R :
1) "Un nom de tableau n'est pas une variable ; donc des instructions telles
que a = pa et a++ [où a est un tableau] sont incorrectes.]"
2) "le *nom* d'un tableau est synonyme de l'adresse de son élément initial".
Jusque là, ça va pour moi. Mais il y a aussi :
3) "Par définition, la valeur d'une variable ou d'une expression de type
tableau est l'adresse de l'élément 0 du tableau"
Pour moi 3) semble dire qu'on puisse parle de variable tableau ce que
contredit clairement 1). Est-il possible d'avoir une explication ?
(peut-être que c'est la traduction, ça m'est déjà arrivé).
Je ne peux pas faire une exégèse du K&R tant qu'on ne m'a pas rendu mon
exemplaire.
Le nom n'est pas la chose qu'il désigne. Mais je doute que ce soit
l'objectif de la phrase. Il faudrait peut-être plus de contexte pour
l'expliquer (et peut-être comparer avec le texte anglais ou même la
première édition pour voir si ce n'est pas quelque chose qui aurait dû être
mieux reformulé).
Pour moi il est clair qu'on peut parler d'une variable de type tableau: il
y a des objets de ce type qui sont nommés, ce qui est la définition
habituelle de variable (il n'y a pas de définition dans la norme, je viens
de regarder toutes les occurences de "variable").
Une lvalue de type tableau (qu'elle soit une variable ou pas) est convertie
dans la plupart des contextes (exceptions: argument de sizeof et de &) en
un pointeur vers son premier élément et le résultat de cette conversion
n'est pas une lvalue. Donc ne peut pas être l'argument de gauche de "=" ou
un argument de ++ qui doivent être des lvalues.
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
Un tableau et un pointeur ont des TYPES différents. Il y a des similitudes entre les deux mais aussi pas mal de différences en sorte que les utilisations ne sont pas interchangeables. Ce qui se passe, c'est que la valeur d'une variable de type tableau est l'adresse de son premier élément NON. La valeur d'une variable de type tableau est le tableau. Ce
tableau, comme tous les autres qu'ils soient des variables ou pas, est converti dans la plupart des contextes en un pointeur vers son premier élément.
En fait, si j'en crois le K&R :
1) "Un nom de tableau n'est pas une variable ; donc des instructions telles que a = pa et a++ [où a est un tableau] sont incorrectes.]"
2) "le *nom* d'un tableau est synonyme de l'adresse de son élément initial".
Jusque là, ça va pour moi. Mais il y a aussi :
3) "Par définition, la valeur d'une variable ou d'une expression de type tableau est l'adresse de l'élément 0 du tableau"
Pour moi 3) semble dire qu'on puisse parle de variable tableau ce que contredit clairement 1). Est-il possible d'avoir une explication ? (peut-être que c'est la traduction, ça m'est déjà arrivé).
Je ne peux pas faire une exégèse du K&R tant qu'on ne m'a pas rendu mon exemplaire.
Le nom n'est pas la chose qu'il désigne. Mais je doute que ce soit l'objectif de la phrase. Il faudrait peut-être plus de contexte pour l'expliquer (et peut-être comparer avec le texte anglais ou même la première édition pour voir si ce n'est pas quelque chose qui aurait dû être mieux reformulé).
Pour moi il est clair qu'on peut parler d'une variable de type tableau: il y a des objets de ce type qui sont nommés, ce qui est la définition habituelle de variable (il n'y a pas de définition dans la norme, je viens de regarder toutes les occurences de "variable").
Une lvalue de type tableau (qu'elle soit une variable ou pas) est convertie dans la plupart des contextes (exceptions: argument de sizeof et de &) en un pointeur vers son premier élément et le résultat de cette conversion n'est pas une lvalue. Donc ne peut pas être l'argument de gauche de "=" ou un argument de ++ qui doivent être des lvalues.
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
Jean-Marc Bourguet
candide writes:
De toute façon, K&R parle de "variable" sans jamais définir ce que c'est, comme ça on peut tout et rien comprendre.
La norme non plus ne donne pas de définition. Mais elle n'utilise pas le nom "variable" très souvent. Si je ne me suis pas trompé, 2 fois seulement dans le texte normatif (donc hors exemples et notes) de C99 et toutes deux dans la partie librairie. La définition classique de variable, c'est objet nommé, donc:
Est-ce que pour eux une variable est un objet,
Par définition, mais tous les objets ne sont pas des variable.
une variable peut-elle être une fonction ?
Une fonction n'est pas objet, donc non.
Est-ce que pour eux une variable c'est une lvalue?
Oui (plus précisément, une expression réduite simplement à un nom de variable est une lvalue). Mais toutes les lvalues ne sont pas des variables.
une lvalue modifiable ? mystère.
Pas nécessairement. Une variable peut être const ou être de type tableau.
Je viens de relire le §1.6 sur les tableaux : mais quelle horreur !
De mémoire, le chapitre dans son ensemble ne se veut pas une description précise mais simplement donner un apperçu du langage.
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
candide <c-candide@wanadoo.fr> writes:
De toute façon, K&R parle de "variable" sans jamais définir ce que
c'est, comme ça on peut tout et rien comprendre.
La norme non plus ne donne pas de définition. Mais elle n'utilise pas le
nom "variable" très souvent. Si je ne me suis pas trompé, 2 fois seulement
dans le texte normatif (donc hors exemples et notes) de C99 et toutes deux
dans la partie librairie. La définition classique de variable, c'est objet
nommé, donc:
Est-ce que pour eux une variable est un objet,
Par définition, mais tous les objets ne sont pas des variable.
une variable peut-elle être une fonction ?
Une fonction n'est pas objet, donc non.
Est-ce que pour eux une variable c'est une lvalue?
Oui (plus précisément, une expression réduite simplement à un nom de
variable est une lvalue). Mais toutes les lvalues ne sont pas des
variables.
une lvalue modifiable ? mystère.
Pas nécessairement. Une variable peut être const ou être de type tableau.
Je viens de relire le §1.6 sur les tableaux : mais quelle horreur !
De mémoire, le chapitre dans son ensemble ne se veut pas une description
précise mais simplement donner un apperçu du langage.
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
De toute façon, K&R parle de "variable" sans jamais définir ce que c'est, comme ça on peut tout et rien comprendre.
La norme non plus ne donne pas de définition. Mais elle n'utilise pas le nom "variable" très souvent. Si je ne me suis pas trompé, 2 fois seulement dans le texte normatif (donc hors exemples et notes) de C99 et toutes deux dans la partie librairie. La définition classique de variable, c'est objet nommé, donc:
Est-ce que pour eux une variable est un objet,
Par définition, mais tous les objets ne sont pas des variable.
une variable peut-elle être une fonction ?
Une fonction n'est pas objet, donc non.
Est-ce que pour eux une variable c'est une lvalue?
Oui (plus précisément, une expression réduite simplement à un nom de variable est une lvalue). Mais toutes les lvalues ne sont pas des variables.
une lvalue modifiable ? mystère.
Pas nécessairement. Une variable peut être const ou être de type tableau.
Je viens de relire le §1.6 sur les tableaux : mais quelle horreur !
De mémoire, le chapitre dans son ensemble ne se veut pas une description précise mais simplement donner un apperçu du langage.
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
Francois
Est-ce que pour eux une variable c'est une lvalue?
Oui (plus précisément, une expression réduite simplement à un nom de variable est une lvalue). Mais toutes les lvalues ne sont pas des variables.
Serait-ce possible que vous me donniez la définition selon vous :
1) d'une variable
2) d'une lvalue
avec le rigorisme qui semble vous caractériser (c'est un compliment pour moi ;-) ) ?
En effet, je pensais que c'était la même chose.
Merci d'avance.
Est-ce que pour eux une variable c'est une lvalue?
Oui (plus précisément, une expression réduite simplement à un nom de
variable est une lvalue). Mais toutes les lvalues ne sont pas des
variables.
Serait-ce possible que vous me donniez la définition selon vous :
1) d'une variable
2) d'une lvalue
avec le rigorisme qui semble vous caractériser (c'est un compliment pour
moi ;-) ) ?
Est-ce que pour eux une variable c'est une lvalue? Oui (plus précisément, une expression réduite simplement à un nom de
variable est une lvalue). Mais toutes les lvalues ne sont pas des variables.
Serait-ce possible que vous me donniez la définition selon vous :
1) d'une variable
J'avais écrit:
La définition classique de variable, c'est objet nommé,
et je n'ai pas de raison d'utiliser une autre dans le contexte du C.
2) d'une lvalue
An lvalue is an expression with an object type or an incomplete type other than void.
int *p; int *pf(); int i;
i, *p et *pf() sont trois lvalues, des trois, seul i est une variable (p est aussi une variable, pf n'en est pas une).
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
candide
On 9 mar, 20:43, Francois wrote:
Je viens de relire le §1.6 sur les tableaux : mais quelle horreur !
Bon, je vais me faire l'avocat du diable en disant que dans le chapitre 1, le but n'est pas d'être complet et précis, mais de faire un tour rapide. C'est dit au début du chapitre.
Je sais bien mais ça ne justifie pas ce que j'ai observé (faire un § sur les tableaux où on ne parle pas de tableaux et où on présente un exemple hyper compliqué)
Par contre au chapitre 5 paragraphe 3 (sur les pointeurs et les tableaux) qui est présente les choses plus rigoureusement, j'ai des soucis. Je ne cherche pas à dire du mal de ce livre (déjà il faudrai t que je lise entièrement), mais je voudrais bien comprendre, c'est tout.
Je trouve que tu débrouilles assez bien.
Tout au début du §5.3 (peu après les dessins), il est dit :
1) "Par définition, la valeur d'une *variable* ou d'une expression de type tableau est l'adresse de l'élément 0 du tableau"
----------------------- By definition, the value of a variable or expression of type array is the address of element zero of the array. -----------------------
puis quelques lignes après :
"Un nom de tableau n'est pas une variable ; donc des instructions telles que a = pa et a++ [où a est un tableau] sont incorrectes.]"
----------------------- A pointer is a variable, so pa=a and pa++ are legal. But an array name is not a variable; constructions like a=pa and a++ are illegal. -----------------------
ce qui me semble contradictoire.
Voilà en effet qui est assez confus. Pour clarifier, va regarder l'annexe A du livre qui dit exactement ceci :
-------------------------------§A.7.1 This conversion does not take place if the expression is in the operand of the unary & operator, or of ++, --, sizeof, or as the left operand of an assignment operator or the . operator. -------------------------------
L'essentiel est de comprendre ceci :
int t[5]={0,1,2,3,4}; int *p; p=t; /* <--- OK */ t=p; /* <--- KO */
avec par exemple l'inconvénient suivant : tu ne peux pas écrire un truc comme ça
while (*t != 4) { printf("%dn", *t); t++; } alors que tu pourras écrire (code complet compilable)
A mon avis il vaudrait mieux ouvrir un nouveau topic si tu veux continuer la discussion.
On 9 mar, 20:43, Francois <mathsatta...@free.fr> wrote:
Je viens de relire le §1.6 sur les tableaux : mais quelle horreur !
Bon, je vais me faire l'avocat du diable en disant que dans le chapitre
1, le but n'est pas d'être complet et précis, mais de faire un tour
rapide. C'est dit au début du chapitre.
Je sais bien mais ça ne justifie pas ce que j'ai observé (faire un §
sur les tableaux où on ne parle pas de tableaux et où on présente un
exemple hyper compliqué)
Par contre au chapitre 5 paragraphe 3 (sur les pointeurs et les
tableaux) qui est présente les choses plus rigoureusement, j'ai des
soucis. Je ne cherche pas à dire du mal de ce livre (déjà il faudrai t
que je lise entièrement), mais je voudrais bien comprendre, c'est tout.
Je trouve que tu débrouilles assez bien.
Tout au début du §5.3 (peu après les dessins), il est dit :
1) "Par définition, la valeur d'une *variable* ou d'une expression de
type tableau est l'adresse de l'élément 0 du tableau"
-----------------------
By definition, the value of a variable or expression of type array is
the address of element zero of the array.
-----------------------
puis quelques lignes après :
"Un nom de tableau n'est pas une variable ; donc des instructions telles
que a = pa et a++ [où a est un tableau] sont incorrectes.]"
-----------------------
A pointer is a variable, so pa=a and pa++ are legal. But an array name
is not a variable; constructions like a=pa and a++ are illegal.
-----------------------
ce qui me semble contradictoire.
Voilà en effet qui est assez confus. Pour clarifier, va regarder
l'annexe A du livre qui dit exactement ceci :
-------------------------------§A.7.1
This conversion does not take place if the expression is in the
operand of the unary & operator, or of ++, --, sizeof, or as the left
operand of an assignment operator or the . operator.
-------------------------------
L'essentiel est de comprendre ceci :
int t[5]={0,1,2,3,4};
int *p;
p=t; /* <--- OK */
t=p; /* <--- KO */
avec par exemple l'inconvénient suivant : tu ne peux pas écrire un
truc comme ça
while (*t != 4)
{
printf("%dn", *t);
t++;
}
alors que tu pourras écrire (code complet compilable)
Je viens de relire le §1.6 sur les tableaux : mais quelle horreur !
Bon, je vais me faire l'avocat du diable en disant que dans le chapitre 1, le but n'est pas d'être complet et précis, mais de faire un tour rapide. C'est dit au début du chapitre.
Je sais bien mais ça ne justifie pas ce que j'ai observé (faire un § sur les tableaux où on ne parle pas de tableaux et où on présente un exemple hyper compliqué)
Par contre au chapitre 5 paragraphe 3 (sur les pointeurs et les tableaux) qui est présente les choses plus rigoureusement, j'ai des soucis. Je ne cherche pas à dire du mal de ce livre (déjà il faudrai t que je lise entièrement), mais je voudrais bien comprendre, c'est tout.
Je trouve que tu débrouilles assez bien.
Tout au début du §5.3 (peu après les dessins), il est dit :
1) "Par définition, la valeur d'une *variable* ou d'une expression de type tableau est l'adresse de l'élément 0 du tableau"
----------------------- By definition, the value of a variable or expression of type array is the address of element zero of the array. -----------------------
puis quelques lignes après :
"Un nom de tableau n'est pas une variable ; donc des instructions telles que a = pa et a++ [où a est un tableau] sont incorrectes.]"
----------------------- A pointer is a variable, so pa=a and pa++ are legal. But an array name is not a variable; constructions like a=pa and a++ are illegal. -----------------------
ce qui me semble contradictoire.
Voilà en effet qui est assez confus. Pour clarifier, va regarder l'annexe A du livre qui dit exactement ceci :
-------------------------------§A.7.1 This conversion does not take place if the expression is in the operand of the unary & operator, or of ++, --, sizeof, or as the left operand of an assignment operator or the . operator. -------------------------------
L'essentiel est de comprendre ceci :
int t[5]={0,1,2,3,4}; int *p; p=t; /* <--- OK */ t=p; /* <--- KO */
avec par exemple l'inconvénient suivant : tu ne peux pas écrire un truc comme ça
while (*t != 4) { printf("%dn", *t); t++; } alors que tu pourras écrire (code complet compilable)
