Si ta référence, pour dire que le K&R est le meilleur livre pour
apprendre le C, sont les ng US, alors, ce n'est même pas la peine de
discuter...
Si ta référence, pour dire que le K&R est le meilleur livre pour
apprendre le C, sont les ng US, alors, ce n'est même pas la peine de
discuter...
Si ta référence, pour dire que le K&R est le meilleur livre pour
apprendre le C, sont les ng US, alors, ce n'est même pas la peine de
discuter...
Alexandre BACQUART a écrit :Comme si le K&R avait pour vocation d'être un "tutoriel"...
Remplace "vocation" par "intention" et observe le titre du chapitre 1 ...
Le résultat est selon moi un fiasco absolu.
Dommage, l'intention était
bonne. En réalité, le livre est très inégal du point de vue de la
pédagogie. Ça mériterait une analyse détaillée à laquelle je me livrerai
peut-être un jour ici même.
de plus, ce livre a 30 ans (presque 20 pour la 2ème édition) !
Qu'est-ce qui vous permet de croire qu'on a pas fait mieux depuis pour
s'initier au C ?
Absolument. S'il y en a qui ont consulté le K&R première version, je
serais curieux de savoir où sont les différences de contenu avec K&R2.
Je suis à peu près convaincu qu'on retrouve à des détails près
exactement la même chose.Quand on est consultant FL > 45 ans, on a tous appris le C avec le
K&R il y a 25 ans et on ne le regrette pas."
This book (widely known as K&R, after the authors' initials) has for
over twenty years been the best way to learn C.
"
On dirait la quatrième de couverture mais google semble renvoyer vers
amazon.com, la critique des lecteurs, ici plus précisément :
http://www.amazon.com/review/product/0131103628?showViewpoints=1
De toute façon, le niveau d'argumentation est proprement sidérant.
Si son niveau en C est comparable, je lui conseille le tuto du site du
zéro, ah! ah! ah!
Alexandre BACQUART a écrit :
Comme si le K&R avait pour vocation d'être un "tutoriel"...
Remplace "vocation" par "intention" et observe le titre du chapitre 1 ...
Le résultat est selon moi un fiasco absolu.
Dommage, l'intention était
bonne. En réalité, le livre est très inégal du point de vue de la
pédagogie. Ça mériterait une analyse détaillée à laquelle je me livrerai
peut-être un jour ici même.
de plus, ce livre a 30 ans (presque 20 pour la 2ème édition) !
Qu'est-ce qui vous permet de croire qu'on a pas fait mieux depuis pour
s'initier au C ?
Absolument. S'il y en a qui ont consulté le K&R première version, je
serais curieux de savoir où sont les différences de contenu avec K&R2.
Je suis à peu près convaincu qu'on retrouve à des détails près
exactement la même chose.
Quand on est consultant FL > 45 ans, on a tous appris le C avec le
K&R il y a 25 ans et on ne le regrette pas.
"
This book (widely known as K&R, after the authors' initials) has for
over twenty years been the best way to learn C.
"
On dirait la quatrième de couverture mais google semble renvoyer vers
amazon.com, la critique des lecteurs, ici plus précisément :
http://www.amazon.com/review/product/0131103628?showViewpoints=1
De toute façon, le niveau d'argumentation est proprement sidérant.
Si son niveau en C est comparable, je lui conseille le tuto du site du
zéro, ah! ah! ah!
Alexandre BACQUART a écrit :Comme si le K&R avait pour vocation d'être un "tutoriel"...
Remplace "vocation" par "intention" et observe le titre du chapitre 1 ...
Le résultat est selon moi un fiasco absolu.
Dommage, l'intention était
bonne. En réalité, le livre est très inégal du point de vue de la
pédagogie. Ça mériterait une analyse détaillée à laquelle je me livrerai
peut-être un jour ici même.
de plus, ce livre a 30 ans (presque 20 pour la 2ème édition) !
Qu'est-ce qui vous permet de croire qu'on a pas fait mieux depuis pour
s'initier au C ?
Absolument. S'il y en a qui ont consulté le K&R première version, je
serais curieux de savoir où sont les différences de contenu avec K&R2.
Je suis à peu près convaincu qu'on retrouve à des détails près
exactement la même chose.Quand on est consultant FL > 45 ans, on a tous appris le C avec le
K&R il y a 25 ans et on ne le regrette pas."
This book (widely known as K&R, after the authors' initials) has for
over twenty years been the best way to learn C.
"
On dirait la quatrième de couverture mais google semble renvoyer vers
amazon.com, la critique des lecteurs, ici plus précisément :
http://www.amazon.com/review/product/0131103628?showViewpoints=1
De toute façon, le niveau d'argumentation est proprement sidérant.
Si son niveau en C est comparable, je lui conseille le tuto du site du
zéro, ah! ah! ah!
Au passage, je vois que quelques pages plus loin, il écrit
enum {FAUX, VRAI};
pratique que tu avais condamné me semble-t-il dans un message antérieur.
Je ne crois pas avoir condamné cette pratique.
Il me semble que j'avais
même écrit :
enum bool {FAUX=0, VRAI=1} /* pour être sûr */
Justement, du point de vue pédagogique, on évite de faire l'erreur
d'énoncer une règle, immédiatement suivie de ses exceptions. On
introduit les exceptions à la règle là où elles sont nécessaires.
Bonne pratique de signaler l'exception seulement quand on parle de
sizeof(tableau) car, sur ce cas, le débutant est en mesure de comprendre
que ce serait absurde de rendre comme résultat la taille du pointeur de
l'adresse du tableau...
Au paragraphe 4.13.2 (intitulé "Cas particulier des chaines
littérales"), il y a un exemple, des commentaires et un dessin qui me
laissent penser que l'auteur ne sait peut-être pas que dans
char *p="Hello";
"Hello" est non modifiable.
Ca veut dire quoi que "Hello" est non modifiable ?
Veux-tu parler du pointeur (créé par le compilateur) qui référence la
chaîne ?
Parce que p[4]='a'; c'est censé marcher, hein ?
Je viens de passer plus d'une heure à regarder le livre, c'est pour
moi un très très mauvais livre d'apprentissage.
Beaucoup moins mauvais que le K&R (pour l'apprentissage, en tout cas).
Au passage, je vois que quelques pages plus loin, il écrit
enum {FAUX, VRAI};
pratique que tu avais condamné me semble-t-il dans un message antérieur.
Je ne crois pas avoir condamné cette pratique.
Il me semble que j'avais
même écrit :
enum bool {FAUX=0, VRAI=1} /* pour être sûr */
Justement, du point de vue pédagogique, on évite de faire l'erreur
d'énoncer une règle, immédiatement suivie de ses exceptions. On
introduit les exceptions à la règle là où elles sont nécessaires.
Bonne pratique de signaler l'exception seulement quand on parle de
sizeof(tableau) car, sur ce cas, le débutant est en mesure de comprendre
que ce serait absurde de rendre comme résultat la taille du pointeur de
l'adresse du tableau...
Au paragraphe 4.13.2 (intitulé "Cas particulier des chaines
littérales"), il y a un exemple, des commentaires et un dessin qui me
laissent penser que l'auteur ne sait peut-être pas que dans
char *p="Hello";
"Hello" est non modifiable.
Ca veut dire quoi que "Hello" est non modifiable ?
Veux-tu parler du pointeur (créé par le compilateur) qui référence la
chaîne ?
Parce que p[4]='a'; c'est censé marcher, hein ?
Je viens de passer plus d'une heure à regarder le livre, c'est pour
moi un très très mauvais livre d'apprentissage.
Beaucoup moins mauvais que le K&R (pour l'apprentissage, en tout cas).
Au passage, je vois que quelques pages plus loin, il écrit
enum {FAUX, VRAI};
pratique que tu avais condamné me semble-t-il dans un message antérieur.
Je ne crois pas avoir condamné cette pratique.
Il me semble que j'avais
même écrit :
enum bool {FAUX=0, VRAI=1} /* pour être sûr */
Justement, du point de vue pédagogique, on évite de faire l'erreur
d'énoncer une règle, immédiatement suivie de ses exceptions. On
introduit les exceptions à la règle là où elles sont nécessaires.
Bonne pratique de signaler l'exception seulement quand on parle de
sizeof(tableau) car, sur ce cas, le débutant est en mesure de comprendre
que ce serait absurde de rendre comme résultat la taille du pointeur de
l'adresse du tableau...
Au paragraphe 4.13.2 (intitulé "Cas particulier des chaines
littérales"), il y a un exemple, des commentaires et un dessin qui me
laissent penser que l'auteur ne sait peut-être pas que dans
char *p="Hello";
"Hello" est non modifiable.
Ca veut dire quoi que "Hello" est non modifiable ?
Veux-tu parler du pointeur (créé par le compilateur) qui référence la
chaîne ?
Parce que p[4]='a'; c'est censé marcher, hein ?
Je viens de passer plus d'une heure à regarder le livre, c'est pour
moi un très très mauvais livre d'apprentissage.
Beaucoup moins mauvais que le K&R (pour l'apprentissage, en tout cas).
"Présentation générale du C" ?
Si
cela ne m'a pas posé trop de problèmes, c'est que j'avais beaucoup
pratiqué l'assembleur avant d'aborder ce bouquin, et ça, ça aide
énormément (les pointeurs passent alors comme une lettre à la poste,
l'OP a d'ailleurs signalé qu'il était embêté avec ça, ce qui est
classique).
Comme je l'ai dit, le débat revient régulièrement ici. Tu devrais sans
peine trouver de l'inspiration dans les archives.
Si je peux me permettre de me faire l'avocat du diable : je ne suis pas
un puriste, donc je n'ai pas grand-chose à en dire de ce site. J'ai
néanmoins jeté un oeil et je ne le trouve pas si mauvais en tant que
tutoriel, même si on peut regretter quelques écarts inutiles, comme le
fait d'utiliser le mot "librairie" en lieu et place de "bibliothèque",
volontairement de son aveu (le genre de choses qui donnera des boutons
aux puristes, mais les puristes ne sont pas censés lire des tutoriels).
Je suis sûr que beaucoup d'apprentis programmeurs y trouvent leur
compte. Je dirai même qu'ils obtiendront des résultats bien plus
rapidement qu'en abordant la chose avec le K&R.
Il ne faut quand-même
pas mélanger ceux qui font cela pour s'amuser, et ceux qui en vivent.
"Présentation générale du C" ?
Si
cela ne m'a pas posé trop de problèmes, c'est que j'avais beaucoup
pratiqué l'assembleur avant d'aborder ce bouquin, et ça, ça aide
énormément (les pointeurs passent alors comme une lettre à la poste,
l'OP a d'ailleurs signalé qu'il était embêté avec ça, ce qui est
classique).
Comme je l'ai dit, le débat revient régulièrement ici. Tu devrais sans
peine trouver de l'inspiration dans les archives.
Si je peux me permettre de me faire l'avocat du diable : je ne suis pas
un puriste, donc je n'ai pas grand-chose à en dire de ce site. J'ai
néanmoins jeté un oeil et je ne le trouve pas si mauvais en tant que
tutoriel, même si on peut regretter quelques écarts inutiles, comme le
fait d'utiliser le mot "librairie" en lieu et place de "bibliothèque",
volontairement de son aveu (le genre de choses qui donnera des boutons
aux puristes, mais les puristes ne sont pas censés lire des tutoriels).
Je suis sûr que beaucoup d'apprentis programmeurs y trouvent leur
compte. Je dirai même qu'ils obtiendront des résultats bien plus
rapidement qu'en abordant la chose avec le K&R.
Il ne faut quand-même
pas mélanger ceux qui font cela pour s'amuser, et ceux qui en vivent.
"Présentation générale du C" ?
Si
cela ne m'a pas posé trop de problèmes, c'est que j'avais beaucoup
pratiqué l'assembleur avant d'aborder ce bouquin, et ça, ça aide
énormément (les pointeurs passent alors comme une lettre à la poste,
l'OP a d'ailleurs signalé qu'il était embêté avec ça, ce qui est
classique).
Comme je l'ai dit, le débat revient régulièrement ici. Tu devrais sans
peine trouver de l'inspiration dans les archives.
Si je peux me permettre de me faire l'avocat du diable : je ne suis pas
un puriste, donc je n'ai pas grand-chose à en dire de ce site. J'ai
néanmoins jeté un oeil et je ne le trouve pas si mauvais en tant que
tutoriel, même si on peut regretter quelques écarts inutiles, comme le
fait d'utiliser le mot "librairie" en lieu et place de "bibliothèque",
volontairement de son aveu (le genre de choses qui donnera des boutons
aux puristes, mais les puristes ne sont pas censés lire des tutoriels).
Je suis sûr que beaucoup d'apprentis programmeurs y trouvent leur
compte. Je dirai même qu'ils obtiendront des résultats bien plus
rapidement qu'en abordant la chose avec le K&R.
Il ne faut quand-même
pas mélanger ceux qui font cela pour s'amuser, et ceux qui en vivent.
Wykaaa a écrit :
Au passage, je vois que quelques pages plus loin, il écrit
enum {FAUX, VRAI};
pratique que tu avais condamné me semble-t-il dans un message antérieur.
Je ne crois pas avoir condamné cette pratique.
SI :
http://groups.google.fr/group/fr.comp.lang.c/msg/65ccae2201c81220?hl=frIl me semble que j'avais même écrit :
enum bool {FAUX=0, VRAI=1} /* pour être sûr */
Oui mais ça c'est différent de ce que j'ai rapporté.
Justement, du point de vue pédagogique, on évite de faire l'erreur
d'énoncer une règle, immédiatement suivie de ses exceptions. On
introduit les exceptions à la règle là où elles sont nécessaires.
Non, absolument pas. Il faut indiquer au moins que des exceptions
existent et faire un renvoi par si les livres de grammaire de nos gamins
étaient écrits comme ça, ils écriraient des bijous (et d'ailleurs, c'est
ce qu'ils font ;) ).
En plus il donne l'impression d'avoir oublié les exceptions et
soudainement de s'en souvenir. En plus, il a oublié le cas &tableau.
Bonne pratique de signaler l'exception seulement quand on parle de
sizeof(tableau) car, sur ce cas, le débutant est en mesure de
comprendre que ce serait absurde de rendre comme résultat la taille du
pointeur de l'adresse du tableau...
D'accord à condition que le lecteur ait été prévenu de l'_existence_ de
ces exceptions, ce qui n'est pas le cas ici. Le principe à appliquer est
un bien connu, c'est le le fameux "Rule of Least Surprise".
Au paragraphe 4.13.2 (intitulé "Cas particulier des chaines
littérales"), il y a un exemple, des commentaires et un dessin qui me
laissent penser que l'auteur ne sait peut-être pas que dans
char *p="Hello";
"Hello" est non modifiable.
Ca veut dire quoi que "Hello" est non modifiable ?
Veux-tu parler du pointeur (créé par le compilateur) qui référence la
chaîne ?
Parce que p[4]='a'; c'est censé marcher, hein ?
Oui, rien dans son exposé ne laisse entendre que ce serait impossible
tellement il fait le parallèle entre
char s[]="hello";/* modifiable */
char *s="hello";/* non modifiable */
Un court de C doit forcément contenir des propos non ambigus là-dessus.
Je viens de passer plus d'une heure à regarder le livre, c'est pour
moi un très très mauvais livre d'apprentissage.
Beaucoup moins mauvais que le K&R (pour l'apprentissage, en tout cas).
Mauvais quand même, je préfère encore K&R.
Wykaaa a écrit :
Au passage, je vois que quelques pages plus loin, il écrit
enum {FAUX, VRAI};
pratique que tu avais condamné me semble-t-il dans un message antérieur.
Je ne crois pas avoir condamné cette pratique.
SI :
http://groups.google.fr/group/fr.comp.lang.c/msg/65ccae2201c81220?hl=fr
Il me semble que j'avais même écrit :
enum bool {FAUX=0, VRAI=1} /* pour être sûr */
Oui mais ça c'est différent de ce que j'ai rapporté.
Justement, du point de vue pédagogique, on évite de faire l'erreur
d'énoncer une règle, immédiatement suivie de ses exceptions. On
introduit les exceptions à la règle là où elles sont nécessaires.
Non, absolument pas. Il faut indiquer au moins que des exceptions
existent et faire un renvoi par si les livres de grammaire de nos gamins
étaient écrits comme ça, ils écriraient des bijous (et d'ailleurs, c'est
ce qu'ils font ;) ).
En plus il donne l'impression d'avoir oublié les exceptions et
soudainement de s'en souvenir. En plus, il a oublié le cas &tableau.
Bonne pratique de signaler l'exception seulement quand on parle de
sizeof(tableau) car, sur ce cas, le débutant est en mesure de
comprendre que ce serait absurde de rendre comme résultat la taille du
pointeur de l'adresse du tableau...
D'accord à condition que le lecteur ait été prévenu de l'_existence_ de
ces exceptions, ce qui n'est pas le cas ici. Le principe à appliquer est
un bien connu, c'est le le fameux "Rule of Least Surprise".
Au paragraphe 4.13.2 (intitulé "Cas particulier des chaines
littérales"), il y a un exemple, des commentaires et un dessin qui me
laissent penser que l'auteur ne sait peut-être pas que dans
char *p="Hello";
"Hello" est non modifiable.
Ca veut dire quoi que "Hello" est non modifiable ?
Veux-tu parler du pointeur (créé par le compilateur) qui référence la
chaîne ?
Parce que p[4]='a'; c'est censé marcher, hein ?
Oui, rien dans son exposé ne laisse entendre que ce serait impossible
tellement il fait le parallèle entre
char s[]="hello";/* modifiable */
char *s="hello";/* non modifiable */
Un court de C doit forcément contenir des propos non ambigus là-dessus.
Je viens de passer plus d'une heure à regarder le livre, c'est pour
moi un très très mauvais livre d'apprentissage.
Beaucoup moins mauvais que le K&R (pour l'apprentissage, en tout cas).
Mauvais quand même, je préfère encore K&R.
Wykaaa a écrit :
Au passage, je vois que quelques pages plus loin, il écrit
enum {FAUX, VRAI};
pratique que tu avais condamné me semble-t-il dans un message antérieur.
Je ne crois pas avoir condamné cette pratique.
SI :
http://groups.google.fr/group/fr.comp.lang.c/msg/65ccae2201c81220?hl=frIl me semble que j'avais même écrit :
enum bool {FAUX=0, VRAI=1} /* pour être sûr */
Oui mais ça c'est différent de ce que j'ai rapporté.
Justement, du point de vue pédagogique, on évite de faire l'erreur
d'énoncer une règle, immédiatement suivie de ses exceptions. On
introduit les exceptions à la règle là où elles sont nécessaires.
Non, absolument pas. Il faut indiquer au moins que des exceptions
existent et faire un renvoi par si les livres de grammaire de nos gamins
étaient écrits comme ça, ils écriraient des bijous (et d'ailleurs, c'est
ce qu'ils font ;) ).
En plus il donne l'impression d'avoir oublié les exceptions et
soudainement de s'en souvenir. En plus, il a oublié le cas &tableau.
Bonne pratique de signaler l'exception seulement quand on parle de
sizeof(tableau) car, sur ce cas, le débutant est en mesure de
comprendre que ce serait absurde de rendre comme résultat la taille du
pointeur de l'adresse du tableau...
D'accord à condition que le lecteur ait été prévenu de l'_existence_ de
ces exceptions, ce qui n'est pas le cas ici. Le principe à appliquer est
un bien connu, c'est le le fameux "Rule of Least Surprise".
Au paragraphe 4.13.2 (intitulé "Cas particulier des chaines
littérales"), il y a un exemple, des commentaires et un dessin qui me
laissent penser que l'auteur ne sait peut-être pas que dans
char *p="Hello";
"Hello" est non modifiable.
Ca veut dire quoi que "Hello" est non modifiable ?
Veux-tu parler du pointeur (créé par le compilateur) qui référence la
chaîne ?
Parce que p[4]='a'; c'est censé marcher, hein ?
Oui, rien dans son exposé ne laisse entendre que ce serait impossible
tellement il fait le parallèle entre
char s[]="hello";/* modifiable */
char *s="hello";/* non modifiable */
Un court de C doit forcément contenir des propos non ambigus là-dessus.
Je viens de passer plus d'une heure à regarder le livre, c'est pour
moi un très très mauvais livre d'apprentissage.
Beaucoup moins mauvais que le K&R (pour l'apprentissage, en tout cas).
Mauvais quand même, je préfère encore K&R.
Un court de C doit forcément contenir des propos non ambigus
Un court de C doit forcément contenir des propos non ambigus
Un court de C doit forcément contenir des propos non ambigus
char s[]="hello";/* modifiable */
char *s="hello";/* non modifiable */
Un court de C doit forcément contenir des propos non ambigus là-dessus.
Là, je suis d'accord car c'est un point très délicat du langage C.
char s[]="hello";/* modifiable */
char *s="hello";/* non modifiable */
Un court de C doit forcément contenir des propos non ambigus là-dessus.
Là, je suis d'accord car c'est un point très délicat du langage C.
char s[]="hello";/* modifiable */
char *s="hello";/* non modifiable */
Un court de C doit forcément contenir des propos non ambigus là-dessus.
Là, je suis d'accord car c'est un point très délicat du langage C.
Alexandre BACQUART a écrit :
"Présentation générale du C" ?
Si c'est la traduction française de "A tutorial Introduction" tu devrais
te procurer la VO.
Si cela ne m'a pas posé trop de problèmes, c'est que j'avais beaucoup
pratiqué l'assembleur avant d'aborder ce bouquin, et ça, ça aide
énormément (les pointeurs passent alors comme une lettre à la poste,
Je note ce point tout à fait intéressant.
l'OP a d'ailleurs signalé qu'il était embêté avec ça, ce qui est
classique).
Pareil pour moi, c'était d'ailleurs l'objet de mon premier message sur
fclc il y a exactement trois ans !
Comme je l'ai dit, le débat revient régulièrement ici. Tu devrais sans
peine trouver de l'inspiration dans les archives.
Franchement, j'en doute, je me sens très inspiré tout seul sur cette
question (qui me tient à coeur).
Si je peux me permettre de me faire l'avocat du diable : je ne suis
pas un puriste, donc je n'ai pas grand-chose à en dire de ce site.
J'ai néanmoins jeté un oeil et je ne le trouve pas si mauvais en tant
que tutoriel, même si on peut regretter quelques écarts inutiles,
comme le fait d'utiliser le mot "librairie" en lieu et place de
"bibliothèque", volontairement de son aveu (le genre de choses qui
donnera des boutons aux puristes, mais les puristes ne sont pas censés
lire des tutoriels).
Cet écart de langage est très fréquent y compris chez des informaticiens
très titrés.
J'ai appris à être tolérants avec ce genre d'écart.
Alexandre BACQUART a écrit :
"Présentation générale du C" ?
Si c'est la traduction française de "A tutorial Introduction" tu devrais
te procurer la VO.
Si cela ne m'a pas posé trop de problèmes, c'est que j'avais beaucoup
pratiqué l'assembleur avant d'aborder ce bouquin, et ça, ça aide
énormément (les pointeurs passent alors comme une lettre à la poste,
Je note ce point tout à fait intéressant.
l'OP a d'ailleurs signalé qu'il était embêté avec ça, ce qui est
classique).
Pareil pour moi, c'était d'ailleurs l'objet de mon premier message sur
fclc il y a exactement trois ans !
Comme je l'ai dit, le débat revient régulièrement ici. Tu devrais sans
peine trouver de l'inspiration dans les archives.
Franchement, j'en doute, je me sens très inspiré tout seul sur cette
question (qui me tient à coeur).
Si je peux me permettre de me faire l'avocat du diable : je ne suis
pas un puriste, donc je n'ai pas grand-chose à en dire de ce site.
J'ai néanmoins jeté un oeil et je ne le trouve pas si mauvais en tant
que tutoriel, même si on peut regretter quelques écarts inutiles,
comme le fait d'utiliser le mot "librairie" en lieu et place de
"bibliothèque", volontairement de son aveu (le genre de choses qui
donnera des boutons aux puristes, mais les puristes ne sont pas censés
lire des tutoriels).
Cet écart de langage est très fréquent y compris chez des informaticiens
très titrés.
J'ai appris à être tolérants avec ce genre d'écart.
Alexandre BACQUART a écrit :
"Présentation générale du C" ?
Si c'est la traduction française de "A tutorial Introduction" tu devrais
te procurer la VO.
Si cela ne m'a pas posé trop de problèmes, c'est que j'avais beaucoup
pratiqué l'assembleur avant d'aborder ce bouquin, et ça, ça aide
énormément (les pointeurs passent alors comme une lettre à la poste,
Je note ce point tout à fait intéressant.
l'OP a d'ailleurs signalé qu'il était embêté avec ça, ce qui est
classique).
Pareil pour moi, c'était d'ailleurs l'objet de mon premier message sur
fclc il y a exactement trois ans !
Comme je l'ai dit, le débat revient régulièrement ici. Tu devrais sans
peine trouver de l'inspiration dans les archives.
Franchement, j'en doute, je me sens très inspiré tout seul sur cette
question (qui me tient à coeur).
Si je peux me permettre de me faire l'avocat du diable : je ne suis
pas un puriste, donc je n'ai pas grand-chose à en dire de ce site.
J'ai néanmoins jeté un oeil et je ne le trouve pas si mauvais en tant
que tutoriel, même si on peut regretter quelques écarts inutiles,
comme le fait d'utiliser le mot "librairie" en lieu et place de
"bibliothèque", volontairement de son aveu (le genre de choses qui
donnera des boutons aux puristes, mais les puristes ne sont pas censés
lire des tutoriels).
Cet écart de langage est très fréquent y compris chez des informaticiens
très titrés.
J'ai appris à être tolérants avec ce genre d'écart.
Dernier point : à ma connaissance, la littérature en assembleur utili se
peu (voire pas) le terme "pointeur" mais plutôt "adresse" (et tout ce
qui va avec, comme les "modes d'adressage").
Dernier point : à ma connaissance, la littérature en assembleur utili se
peu (voire pas) le terme "pointeur" mais plutôt "adresse" (et tout ce
qui va avec, comme les "modes d'adressage").
Dernier point : à ma connaissance, la littérature en assembleur utili se
peu (voire pas) le terme "pointeur" mais plutôt "adresse" (et tout ce
qui va avec, comme les "modes d'adressage").
On 10 août, 00:14, Alexandre BACQUART wrote:Dernier point : à ma connaissance, la littérature en assembleur utilise
peu (voire pas) le terme "pointeur" mais plutôt "adresse" (et tout ce
qui va avec, comme les "modes d'adressage").
Ce n'est pas la même chose.
En assembleur ou en C, une adresse c'est
une valeur constante (ASM : valeur immédiate, C : expression constante
ou pointeur constant) qui désigne un objet en mémoire.
On peut utiliser cette adresse pour accéder à cette mémoire via une
opération de déréferencement (ASM : (A0), SP:[BP] C : *p) d'une
mémoire contenant la valeur de cette adresse. Pour désigner ce genre
de mémoire, en assembleur, on parle de registre d'adresse, et en C, C+
+, Pascal, Ada etc, on parle de pointeur.
Il n'y a pas lieu de confondre adresse et pointeur.
On 10 août, 00:14, Alexandre BACQUART <tek...@free.DELETEME.fr> wrote:
Dernier point : à ma connaissance, la littérature en assembleur utilise
peu (voire pas) le terme "pointeur" mais plutôt "adresse" (et tout ce
qui va avec, comme les "modes d'adressage").
Ce n'est pas la même chose.
En assembleur ou en C, une adresse c'est
une valeur constante (ASM : valeur immédiate, C : expression constante
ou pointeur constant) qui désigne un objet en mémoire.
On peut utiliser cette adresse pour accéder à cette mémoire via une
opération de déréferencement (ASM : (A0), SP:[BP] C : *p) d'une
mémoire contenant la valeur de cette adresse. Pour désigner ce genre
de mémoire, en assembleur, on parle de registre d'adresse, et en C, C+
+, Pascal, Ada etc, on parle de pointeur.
Il n'y a pas lieu de confondre adresse et pointeur.
On 10 août, 00:14, Alexandre BACQUART wrote:Dernier point : à ma connaissance, la littérature en assembleur utilise
peu (voire pas) le terme "pointeur" mais plutôt "adresse" (et tout ce
qui va avec, comme les "modes d'adressage").
Ce n'est pas la même chose.
En assembleur ou en C, une adresse c'est
une valeur constante (ASM : valeur immédiate, C : expression constante
ou pointeur constant) qui désigne un objet en mémoire.
On peut utiliser cette adresse pour accéder à cette mémoire via une
opération de déréferencement (ASM : (A0), SP:[BP] C : *p) d'une
mémoire contenant la valeur de cette adresse. Pour désigner ce genre
de mémoire, en assembleur, on parle de registre d'adresse, et en C, C+
+, Pascal, Ada etc, on parle de pointeur.
Il n'y a pas lieu de confondre adresse et pointeur.