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)
T'as regardé le tuto de éo sur le site du zéro avant de le critiquer ? Il est super bien fait, Je viens d'aller voir... je ne suis pas impressionné.
Moi non plus.
Ca te gènerait beaucoup d'être consistant?
Je le suis, j'ai dit qu'il était "super bien fait", j'ai été effectivement un peu rapide puisque je me suis en fait basé sur le tutorial sur la bibliothèque graphique SDL que j'ai trouvé très bien fait et j'ai extrapolé. Je n'ai jamais dit que j'ai été impressionné par les tuto de matéo21, si je devais faire quelque chose, ce serait certainement très différent mais je garderais certains éléments de son approche. Je persiste à dire que si j'avais appris le C via ce tuto, j'aurais gagné 1 an dans mon apprentissage (j'en suis à deux ans et demi). Et pourtant je ne suis pas rétif aux abstractions.
candide <c-candide@wanadoo.fr> writes:
On 9 mar, 15:05, Jean-Marc Bourguet <j...@bourguet.org> wrote:
candide <c-candide@wanadoo.fr> writes:
T'as regardé le tuto de m@téo sur le site
du zéro avant de le critiquer ? Il est super bien fait,
Je viens d'aller voir... je ne suis pas impressionné.
Moi non plus.
Ca te gènerait beaucoup d'être consistant?
Je le suis, j'ai dit qu'il était "super bien fait", j'ai été
effectivement un peu rapide puisque je me suis en fait basé sur le
tutorial sur la bibliothèque graphique SDL que j'ai trouvé très bien
fait et j'ai extrapolé. Je n'ai jamais dit que j'ai été impressionné par
les tuto de matéo21, si je devais faire quelque chose, ce serait
certainement très différent mais je garderais certains éléments de son
approche. Je persiste à dire que si j'avais appris le C via ce tuto,
j'aurais gagné 1 an dans mon apprentissage (j'en suis à deux ans et
demi). Et pourtant je ne suis pas rétif aux abstractions.
T'as regardé le tuto de éo sur le site du zéro avant de le critiquer ? Il est super bien fait, Je viens d'aller voir... je ne suis pas impressionné.
Moi non plus.
Ca te gènerait beaucoup d'être consistant?
Je le suis, j'ai dit qu'il était "super bien fait", j'ai été effectivement un peu rapide puisque je me suis en fait basé sur le tutorial sur la bibliothèque graphique SDL que j'ai trouvé très bien fait et j'ai extrapolé. Je n'ai jamais dit que j'ai été impressionné par les tuto de matéo21, si je devais faire quelque chose, ce serait certainement très différent mais je garderais certains éléments de son approche. Je persiste à dire que si j'avais appris le C via ce tuto, j'aurais gagné 1 an dans mon apprentissage (j'en suis à deux ans et demi). Et pourtant je ne suis pas rétif aux abstractions.
Jean-Marc Bourguet
Francois writes:
On constate même que c'est nuisible d'avoir un modèle trop précis d'implémentation.
Disons qu'il faudrait que l'auteur soit honnête avec son lecteur, que sur certains passages d'explications l'auteur cesse de parler du langage C et que les choses peuvent se passer différemment suivant la plate-forme.
Ce sont des messages qui ne passent pas. Comme montrer quelque chose en disant que c'est tentant mais à ne pas faire et donner de suite la bonne méthode, ça ne passe pas non plus: il y a plus de gens qui font l'erreur que si tu n'avais pas averti!
Bon, ça (complément à 2 etc.) encore, on le trouve dans les livres (pas le K&R il me semble ?). Mais par exemple, j'ai constaté qu'avec :
signed char var = 255 ;
le compilateur ne gueule pas (pas le mien en tout cas). Ah ! J'aimerais qu'on me dise que le compilateur va le coder bravement, puis que l'ordinateur pendant l'exécution (ou le compilateur pendant la compilation j'en sais rien) va interpréter "var" en tant que "signed char" et que donc je vais avoir des surprises lorsque je vais utiliser cette variable.
J'aimerais bien comprendre en revanche pourquoi avec :
signed char var = -129 ;
là par contre, le compilateur gueule.
Ce doit être un warning. A mon avis, il ferais bien de donner des warnings dans les deux cas. gcc a le comportement que tu décris et
signed bar = 256;
génère aussi un warning. Je ne sais pas pourquoi ils ont décidé de ne pas donner de warning pour des valeurs inférieure à 256.
Pourtant, il pourrait très bien faire son code sans rien me dire comme précédemment. Mais non, chez moi, là, il gueule. Doucement remarque, car quand je recompile juste après, le message ne s'affiche plus. On peut dire que c'est une sorte de warning.
Ce ne serait-ce pas plutôt à cause qu'il ne recompile pas ce fichier parce que rien ne l'impose?
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:
On constate même que c'est nuisible d'avoir un modèle trop précis
d'implémentation.
Disons qu'il faudrait que l'auteur soit honnête avec son lecteur, que sur
certains passages d'explications l'auteur cesse de parler du langage C et
que les choses peuvent se passer différemment suivant la plate-forme.
Ce sont des messages qui ne passent pas. Comme montrer quelque chose en
disant que c'est tentant mais à ne pas faire et donner de suite la bonne
méthode, ça ne passe pas non plus: il y a plus de gens qui font l'erreur
que si tu n'avais pas averti!
Bon, ça (complément à 2 etc.) encore, on le trouve dans les livres (pas le
K&R il me semble ?). Mais par exemple, j'ai constaté qu'avec :
signed char var = 255 ;
le compilateur ne gueule pas (pas le mien en tout cas). Ah ! J'aimerais
qu'on me dise que le compilateur va le coder bravement, puis que
l'ordinateur pendant l'exécution (ou le compilateur pendant la compilation
j'en sais rien) va interpréter "var" en tant que "signed char" et que donc
je vais avoir des surprises lorsque je vais utiliser cette variable.
J'aimerais bien comprendre en revanche pourquoi avec :
signed char var = -129 ;
là par contre, le compilateur gueule.
Ce doit être un warning. A mon avis, il ferais bien de donner des warnings
dans les deux cas. gcc a le comportement que tu décris et
signed bar = 256;
génère aussi un warning. Je ne sais pas pourquoi ils ont décidé de ne pas
donner de warning pour des valeurs inférieure à 256.
Pourtant, il pourrait très bien faire son code sans rien me dire comme
précédemment. Mais non, chez moi, là, il gueule. Doucement remarque, car
quand je recompile juste après, le message ne s'affiche plus. On peut
dire que c'est une sorte de warning.
Ce ne serait-ce pas plutôt à cause qu'il ne recompile pas ce fichier parce
que rien ne l'impose?
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
On constate même que c'est nuisible d'avoir un modèle trop précis d'implémentation.
Disons qu'il faudrait que l'auteur soit honnête avec son lecteur, que sur certains passages d'explications l'auteur cesse de parler du langage C et que les choses peuvent se passer différemment suivant la plate-forme.
Ce sont des messages qui ne passent pas. Comme montrer quelque chose en disant que c'est tentant mais à ne pas faire et donner de suite la bonne méthode, ça ne passe pas non plus: il y a plus de gens qui font l'erreur que si tu n'avais pas averti!
Bon, ça (complément à 2 etc.) encore, on le trouve dans les livres (pas le K&R il me semble ?). Mais par exemple, j'ai constaté qu'avec :
signed char var = 255 ;
le compilateur ne gueule pas (pas le mien en tout cas). Ah ! J'aimerais qu'on me dise que le compilateur va le coder bravement, puis que l'ordinateur pendant l'exécution (ou le compilateur pendant la compilation j'en sais rien) va interpréter "var" en tant que "signed char" et que donc je vais avoir des surprises lorsque je vais utiliser cette variable.
J'aimerais bien comprendre en revanche pourquoi avec :
signed char var = -129 ;
là par contre, le compilateur gueule.
Ce doit être un warning. A mon avis, il ferais bien de donner des warnings dans les deux cas. gcc a le comportement que tu décris et
signed bar = 256;
génère aussi un warning. Je ne sais pas pourquoi ils ont décidé de ne pas donner de warning pour des valeurs inférieure à 256.
Pourtant, il pourrait très bien faire son code sans rien me dire comme précédemment. Mais non, chez moi, là, il gueule. Doucement remarque, car quand je recompile juste après, le message ne s'affiche plus. On peut dire que c'est une sorte de warning.
Ce ne serait-ce pas plutôt à cause qu'il ne recompile pas ce fichier parce que rien ne l'impose?
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, 16:28, Francois wrote:
Au même titre que dans un livre de maths (théorèmes + démonstratio ns), il y a des remarques (par exemple : "dans la pratique on appliquera ce théorème dans telle situation" ou "finalement dans cette longue et indigeste démonstration, c'est très simple, on ne fait qu'appliquer ce ci ..., le fil rouge est ...) qui aident, parfois de manière cruciale, à comprendre les choses. Pourtant, et c'est parfaitement clair pour le lecteur, ces remarques éclairantes cessent d'être des mathématiques (ce ne sont pas des énoncés mathématiques). J'espère être clair ?
Tu es parfaitement clair, j'approuve pleinement ton propos mais ça ne veut pas dire que tu vas être compris par ceux qui vont te lire.
On 9 mar, 16:28, Francois <mathsatta...@free.fr> wrote:
Au même titre que dans un livre de maths (théorèmes + démonstratio ns),
il y a des remarques (par exemple : "dans la pratique on appliquera ce
théorème dans telle situation" ou "finalement dans cette longue et
indigeste démonstration, c'est très simple, on ne fait qu'appliquer ce ci
..., le fil rouge est ...) qui aident, parfois de manière cruciale, à
comprendre les choses. Pourtant, et c'est parfaitement clair pour le
lecteur, ces remarques éclairantes cessent d'être des mathématiques (ce
ne sont pas des énoncés mathématiques).
J'espère être clair ?
Tu es parfaitement clair, j'approuve pleinement ton propos mais ça ne
veut pas dire que tu vas être compris par ceux qui vont te lire.
Au même titre que dans un livre de maths (théorèmes + démonstratio ns), il y a des remarques (par exemple : "dans la pratique on appliquera ce théorème dans telle situation" ou "finalement dans cette longue et indigeste démonstration, c'est très simple, on ne fait qu'appliquer ce ci ..., le fil rouge est ...) qui aident, parfois de manière cruciale, à comprendre les choses. Pourtant, et c'est parfaitement clair pour le lecteur, ces remarques éclairantes cessent d'être des mathématiques (ce ne sont pas des énoncés mathématiques). J'espère être clair ?
Tu es parfaitement clair, j'approuve pleinement ton propos mais ça ne veut pas dire que tu vas être compris par ceux qui vont te lire.
candide
On 9 mar, 16:55, Michel <nospam> wrote:
Et il a combien d'années (ou décennies) d'expérience cet enfant pour
Argument d'autorité.
pouvoir proposer un tutorial ?!
On te demande de juger sur pièces, alors examine le texte et formule tes critiques, en faisant des citations précises.
On 9 mar, 16:55, Michel <nospam> wrote:
Et il a combien d'années (ou décennies) d'expérience cet enfant pour
Argument d'autorité.
pouvoir proposer un tutorial ?!
On te demande de juger sur pièces, alors examine le texte et formule
tes critiques, en faisant des citations précises.
Alors c'est cette autre FAQ qu'il faut lire :http://www.seebs.net/faqs/c-i aq.html
Merci, je ne la connaissais pas mais ça m'a l'air bien léger.
Francois
Je viens d'aller voir... je ne suis pas impressionné. Il échoue à mes trois tests: - int ça permet de stocker des nombres de -2^31-1 à 2^31 - double ça permet de stocker des nombres décimaux - confusion tableau/pointeur
Je crois que le problème vient du fait que nous ne nous basons par sur les mêmes critères. Candide et moi invoquions des critères de pédagogie, alors que vous évoquez des critères de précisions (bien que les deux notions ne soient pas indépendantes loin de là c'est vrai).
Serait-ce trop demander d'avoir des précisions sur vos tests (je demande cela par intérêt et sans aucune arrière pensée) ?
Pour le premier je pense que Candide a déjà répondu.
Mais pour les tests 2 et 3, j'aimerais bien savoir ce que vous attendez pour que les tests soient réussis. J'avoue ne pas voir exactement.
François
Je viens d'aller voir... je ne suis pas impressionné. Il échoue à mes
trois tests:
- int ça permet de stocker des nombres de -2^31-1 à 2^31
- double ça permet de stocker des nombres décimaux
- confusion tableau/pointeur
Je crois que le problème vient du fait que nous ne nous basons par sur
les mêmes critères. Candide et moi invoquions des critères de pédagogie,
alors que vous évoquez des critères de précisions (bien que les deux
notions ne soient pas indépendantes loin de là c'est vrai).
Serait-ce trop demander d'avoir des précisions sur vos tests (je demande
cela par intérêt et sans aucune arrière pensée) ?
Pour le premier je pense que Candide a déjà répondu.
Mais pour les tests 2 et 3, j'aimerais bien savoir ce que vous attendez
pour que les tests soient réussis. J'avoue ne pas voir exactement.
Je viens d'aller voir... je ne suis pas impressionné. Il échoue à mes trois tests: - int ça permet de stocker des nombres de -2^31-1 à 2^31 - double ça permet de stocker des nombres décimaux - confusion tableau/pointeur
Je crois que le problème vient du fait que nous ne nous basons par sur les mêmes critères. Candide et moi invoquions des critères de pédagogie, alors que vous évoquez des critères de précisions (bien que les deux notions ne soient pas indépendantes loin de là c'est vrai).
Serait-ce trop demander d'avoir des précisions sur vos tests (je demande cela par intérêt et sans aucune arrière pensée) ?
Pour le premier je pense que Candide a déjà répondu.
Mais pour les tests 2 et 3, j'aimerais bien savoir ce que vous attendez pour que les tests soient réussis. J'avoue ne pas voir exactement.
François
Francois
Ce sont des messages qui ne passent pas. Comme montrer quelque chose en disant que c'est tentant mais à ne pas faire et donner de suite la bonne méthode, ça ne passe pas non plus: il y a plus de gens qui font l'erreur que si tu n'avais pas averti!
Humm, mais c'est de la rétention d'information, ça (dont l'intention est louable bien sûr). C'est une question de goût, mais je ne suis pas d'accord avec cela.
génère aussi un warning. Je ne sais pas pourquoi ils ont décidé de ne pas donner de warning pour des valeurs inférieure à 256.
D'accord, c'est une histoire de compilateur plus ou moins permissif donc.
Ce sont des messages qui ne passent pas. Comme montrer quelque chose en
disant que c'est tentant mais à ne pas faire et donner de suite la bonne
méthode, ça ne passe pas non plus: il y a plus de gens qui font l'erreur
que si tu n'avais pas averti!
Humm, mais c'est de la rétention d'information, ça (dont l'intention est
louable bien sûr). C'est une question de goût, mais je ne suis pas
d'accord avec cela.
génère aussi un warning. Je ne sais pas pourquoi ils ont décidé de ne pas
donner de warning pour des valeurs inférieure à 256.
D'accord, c'est une histoire de compilateur plus ou moins permissif donc.
Ce sont des messages qui ne passent pas. Comme montrer quelque chose en disant que c'est tentant mais à ne pas faire et donner de suite la bonne méthode, ça ne passe pas non plus: il y a plus de gens qui font l'erreur que si tu n'avais pas averti!
Humm, mais c'est de la rétention d'information, ça (dont l'intention est louable bien sûr). C'est une question de goût, mais je ne suis pas d'accord avec cela.
génère aussi un warning. Je ne sais pas pourquoi ils ont décidé de ne pas donner de warning pour des valeurs inférieure à 256.
D'accord, c'est une histoire de compilateur plus ou moins permissif donc.
Anthony Fleury
Bonjour,
On constate même que c'est nuisible d'avoir un modèle trop précis d'implémentation.
Disons qu'il faudrait que l'auteur soit honnête avec son lecteur, que sur certains passages d'explications l'auteur cesse de parler du langage C et que les choses peuvent se passer différemment suivant la plate-forme. Au même titre que dans un livre de maths (théorèmes + démonstrations), il y a des remarques (par exemple : "dans la pratique on appliquera ce théorème dans telle situation" ou "finalement dans cette longue et indigeste démonstration, c'est très simple, on ne fait qu'appliquer ceci ..., le fil rouge est ...) qui aident, parfois de manière cruciale, à comprendre les choses. Pourtant, et c'est parfaitement clair pour le lecteur, ces remarques éclairantes cessent d'être des mathématiques (ce ne sont pas des énoncés mathématiques). J'espère être clair ?
Depuis le début je trouve la demande assez claire, mais je ne trouve pas que ce soit une bonne idée. En effet, comme il a déjà été dit, le C est fait pour être portable. On apprend donc, dans les bons livres, un ensemble de règles qui font qu'un programme pourra tourner sur un pc x86, un x86-64, un DSP texas, un PIC de chez microchip etc.
Pourtant en effet toutes ces architectures sont bien différentes et peuvent aussi avoir en effet des tailles de bytes différents, mais ça je ne pense pas qu'on ait à le savoir avant d'avoir à coder quelque chose de précis utilisant une valeur de char en dehors de [-127;127] sur un DSP.
Pour moi, l'apprentissage se fait en deux phases : - la première on apprend à programmer et à écrire du code propre - la seconde on regarde son architecture, son comportement, on s'intéresse aux autres archi etc. Mais avant de faire cela, il faut apprendre à écrire du code assez propre.
Lorsque l'on enseigne le C, même lorsque l'on enseigne les pointeurs, on arrive à faire passer le message aux élèves même sans leur cacher de chose, sans faire entrer un brin d'architecture. Le message reçu n'en est que plus clair (pour moi). Sinon, son contenu n'est pas clair dès le départ car il mélange deux problématiques, c'est le meilleur moyen de ne rien apprendre.
Le C a déjà de nombreux points problématiques à expliquer (pointeurs, tableaux, etc.), ces points justement qui sont mal expliqués en général dans les tutoriels en ligne.
Un message qui pour moi est consistant est de séparer les enseignements. D'abord enseigner le C lorsque l'on veut l'enseigner, sans notion d'architecture et en respectant la norme qui le décrit (on nous enseigne en général l'anglais avec ses constructions, et non une version américaine de celui-ci avec ses spécificités, sachant que le premier sera compréhensible autant par des américains que des anglais que des australiens). Ensuite, enseigner l'architecture, se baser soit sur des architectures inventées et définies avec un assembleur défini par l'auteur, soit se baser sur une architecture RISC ou CISC existante (il y a de très bons livres sur le sujet, que ce soit sur Intel ou autre).
Mieux vaut deux livres bien construits qu'un unique livre qui mélange les genres et va embrouiller le lecteur à la première difficulté.
Cependant, ce n'est qu'un simple avis.
Anthony
Bonjour,
On constate même que c'est nuisible d'avoir un modèle trop précis
d'implémentation.
Disons qu'il faudrait que l'auteur soit honnête avec son lecteur, que
sur certains passages d'explications l'auteur cesse de parler du langage
C et que les choses peuvent se passer différemment suivant la plate-forme.
Au même titre que dans un livre de maths (théorèmes + démonstrations),
il y a des remarques (par exemple : "dans la pratique on appliquera ce
théorème dans telle situation" ou "finalement dans cette longue et
indigeste démonstration, c'est très simple, on ne fait qu'appliquer ceci
..., le fil rouge est ...) qui aident, parfois de manière cruciale, à
comprendre les choses. Pourtant, et c'est parfaitement clair pour le
lecteur, ces remarques éclairantes cessent d'être des mathématiques (ce
ne sont pas des énoncés mathématiques).
J'espère être clair ?
Depuis le début je trouve la demande assez claire, mais je ne trouve pas
que ce soit une bonne idée.
En effet, comme il a déjà été dit, le C est fait pour être portable. On
apprend donc, dans les bons livres, un ensemble de règles qui font qu'un
programme pourra tourner sur un pc x86, un x86-64, un DSP texas, un PIC
de chez microchip etc.
Pourtant en effet toutes ces architectures sont bien différentes et
peuvent aussi avoir en effet des tailles de bytes différents, mais ça je
ne pense pas qu'on ait à le savoir avant d'avoir à coder quelque chose
de précis utilisant une valeur de char en dehors de [-127;127] sur un DSP.
Pour moi, l'apprentissage se fait en deux phases :
- la première on apprend à programmer et à écrire du code propre
- la seconde on regarde son architecture, son comportement, on
s'intéresse aux autres archi etc. Mais avant de faire cela, il faut
apprendre à écrire du code assez propre.
Lorsque l'on enseigne le C, même lorsque l'on enseigne les pointeurs, on
arrive à faire passer le message aux élèves même sans leur cacher de
chose, sans faire entrer un brin d'architecture. Le message reçu n'en
est que plus clair (pour moi).
Sinon, son contenu n'est pas clair dès le départ car il mélange deux
problématiques, c'est le meilleur moyen de ne rien apprendre.
Le C a déjà de nombreux points problématiques à expliquer (pointeurs,
tableaux, etc.), ces points justement qui sont mal expliqués en général
dans les tutoriels en ligne.
Un message qui pour moi est consistant est de séparer les enseignements.
D'abord enseigner le C lorsque l'on veut l'enseigner, sans notion
d'architecture et en respectant la norme qui le décrit (on nous enseigne
en général l'anglais avec ses constructions, et non une version
américaine de celui-ci avec ses spécificités, sachant que le premier
sera compréhensible autant par des américains que des anglais que des
australiens). Ensuite, enseigner l'architecture, se baser soit sur des
architectures inventées et définies avec un assembleur défini par
l'auteur, soit se baser sur une architecture RISC ou CISC existante (il
y a de très bons livres sur le sujet, que ce soit sur Intel ou autre).
Mieux vaut deux livres bien construits qu'un unique livre qui mélange
les genres et va embrouiller le lecteur à la première difficulté.
On constate même que c'est nuisible d'avoir un modèle trop précis d'implémentation.
Disons qu'il faudrait que l'auteur soit honnête avec son lecteur, que sur certains passages d'explications l'auteur cesse de parler du langage C et que les choses peuvent se passer différemment suivant la plate-forme. Au même titre que dans un livre de maths (théorèmes + démonstrations), il y a des remarques (par exemple : "dans la pratique on appliquera ce théorème dans telle situation" ou "finalement dans cette longue et indigeste démonstration, c'est très simple, on ne fait qu'appliquer ceci ..., le fil rouge est ...) qui aident, parfois de manière cruciale, à comprendre les choses. Pourtant, et c'est parfaitement clair pour le lecteur, ces remarques éclairantes cessent d'être des mathématiques (ce ne sont pas des énoncés mathématiques). J'espère être clair ?
Depuis le début je trouve la demande assez claire, mais je ne trouve pas que ce soit une bonne idée. En effet, comme il a déjà été dit, le C est fait pour être portable. On apprend donc, dans les bons livres, un ensemble de règles qui font qu'un programme pourra tourner sur un pc x86, un x86-64, un DSP texas, un PIC de chez microchip etc.
Pourtant en effet toutes ces architectures sont bien différentes et peuvent aussi avoir en effet des tailles de bytes différents, mais ça je ne pense pas qu'on ait à le savoir avant d'avoir à coder quelque chose de précis utilisant une valeur de char en dehors de [-127;127] sur un DSP.
Pour moi, l'apprentissage se fait en deux phases : - la première on apprend à programmer et à écrire du code propre - la seconde on regarde son architecture, son comportement, on s'intéresse aux autres archi etc. Mais avant de faire cela, il faut apprendre à écrire du code assez propre.
Lorsque l'on enseigne le C, même lorsque l'on enseigne les pointeurs, on arrive à faire passer le message aux élèves même sans leur cacher de chose, sans faire entrer un brin d'architecture. Le message reçu n'en est que plus clair (pour moi). Sinon, son contenu n'est pas clair dès le départ car il mélange deux problématiques, c'est le meilleur moyen de ne rien apprendre.
Le C a déjà de nombreux points problématiques à expliquer (pointeurs, tableaux, etc.), ces points justement qui sont mal expliqués en général dans les tutoriels en ligne.
Un message qui pour moi est consistant est de séparer les enseignements. D'abord enseigner le C lorsque l'on veut l'enseigner, sans notion d'architecture et en respectant la norme qui le décrit (on nous enseigne en général l'anglais avec ses constructions, et non une version américaine de celui-ci avec ses spécificités, sachant que le premier sera compréhensible autant par des américains que des anglais que des australiens). Ensuite, enseigner l'architecture, se baser soit sur des architectures inventées et définies avec un assembleur défini par l'auteur, soit se baser sur une architecture RISC ou CISC existante (il y a de très bons livres sur le sujet, que ce soit sur Intel ou autre).
Mieux vaut deux livres bien construits qu'un unique livre qui mélange les genres et va embrouiller le lecteur à la première difficulté.
Cependant, ce n'est qu'un simple avis.
Anthony
Jean-Marc Bourguet
candide writes:
Je viens d'avoir quelques problèmes d'envoi non désiré avec usenet sur Google, je réinstalle un lecteur de news, j'espère que ça va aller mieux. Désolé pour le bruit.
Je viens d'aller voir... je ne suis pas impressionné. Il échoue à mes trois tests:
Moi aussi ,j'ai une batterie de test mais alors on n'a pas DU TOUT les mêmes critères.
Tant qu'on n'a pas un niveau minimum de rigueur technique, les qualités pédagogiques sont un désavantage: non seulement on enseigne des choses fausses, mais en plus on le fait bien ce qui les incruste!
- int ça permet de stocker des nombres de -2^31-1 à 2^31
Bon, j'ai dit que ce n'était pas rédhibitoire, c'est un manque de précaution oratoire. Il suffit juste de préciser que ce n'est valable que sur certaines architectures et que sur des PC sous Windows ou Linux avec gcc c'est assez courant. Ce n'est pas le genre de détails sur lequel il faut insister au départ, il ne faut pas l'ignorer, c'est tout.
Tu avais écrit qu'il y avait très peu d'approximation et de choses non portables. On sait maintenant que tu faisais référence à un autre tutorial...
D'ailleurs, je ne vois pas en quoi le tuto a besoin de savoir que les entiers sont sur 32 bits.
C'est exactement mon point.
- double ça permet de stocker des nombres décimaux
Et alors ? quel est véritablement le problème, le terme "décimaux" n'est pas approprié, rien de plus. Dans la pratique c'est souvent comme ça et tout le monde comprend de quoi il s'agit.
K&R définit un float ainsi :
---------------------- by contrast with float, which means floating point, i.e., numbers that may have a fractional part. ----------------------
Il n'est pas précisé qu'elle est décimale... et c'est bien! La plupart des problèmes que rencontrent les débutants -- et des moins débutants aussi -- avec les flottants sont dus au fait que les flottants ne sont pas décimaux. Le plus navrant, c'est qu'ils en concluent qu'il s'agit de problème de précision (ce qui est faux, c'est un probléme de quantification).
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:
Je viens d'avoir quelques problèmes d'envoi non désiré avec usenet sur
Google, je réinstalle un lecteur de news, j'espère que ça va aller
mieux. Désolé pour le bruit.
Je viens d'aller voir... je ne suis pas impressionné. Il échoue à mes
trois tests:
Moi aussi ,j'ai une batterie de test mais alors on n'a pas DU TOUT les
mêmes critères.
Tant qu'on n'a pas un niveau minimum de rigueur technique, les qualités
pédagogiques sont un désavantage: non seulement on enseigne des choses
fausses, mais en plus on le fait bien ce qui les incruste!
- int ça permet de stocker des nombres de -2^31-1 à 2^31
Bon, j'ai dit que ce n'était pas rédhibitoire, c'est un manque de
précaution oratoire. Il suffit juste de préciser que ce n'est valable que
sur certaines architectures et que sur des PC sous Windows ou Linux avec
gcc c'est assez courant. Ce n'est pas le genre de détails sur lequel il
faut insister au départ, il ne faut pas l'ignorer, c'est tout.
Tu avais écrit qu'il y avait très peu d'approximation et de choses non
portables. On sait maintenant que tu faisais référence à un autre
tutorial...
D'ailleurs, je ne vois pas en quoi le tuto a besoin de savoir que les
entiers sont sur 32 bits.
C'est exactement mon point.
- double ça permet de stocker des nombres décimaux
Et alors ? quel est véritablement le problème, le terme "décimaux" n'est
pas approprié, rien de plus. Dans la pratique c'est souvent comme ça et
tout le monde comprend de quoi il s'agit.
K&R définit un float ainsi :
----------------------
by contrast with float, which means floating point, i.e., numbers that may
have a fractional part.
----------------------
Il n'est pas précisé qu'elle est décimale... et c'est bien! La plupart des
problèmes que rencontrent les débutants -- et des moins débutants aussi --
avec les flottants sont dus au fait que les flottants ne sont pas décimaux.
Le plus navrant, c'est qu'ils en concluent qu'il s'agit de problème de
précision (ce qui est faux, c'est un probléme de quantification).
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
Je viens d'avoir quelques problèmes d'envoi non désiré avec usenet sur Google, je réinstalle un lecteur de news, j'espère que ça va aller mieux. Désolé pour le bruit.
Je viens d'aller voir... je ne suis pas impressionné. Il échoue à mes trois tests:
Moi aussi ,j'ai une batterie de test mais alors on n'a pas DU TOUT les mêmes critères.
Tant qu'on n'a pas un niveau minimum de rigueur technique, les qualités pédagogiques sont un désavantage: non seulement on enseigne des choses fausses, mais en plus on le fait bien ce qui les incruste!
- int ça permet de stocker des nombres de -2^31-1 à 2^31
Bon, j'ai dit que ce n'était pas rédhibitoire, c'est un manque de précaution oratoire. Il suffit juste de préciser que ce n'est valable que sur certaines architectures et que sur des PC sous Windows ou Linux avec gcc c'est assez courant. Ce n'est pas le genre de détails sur lequel il faut insister au départ, il ne faut pas l'ignorer, c'est tout.
Tu avais écrit qu'il y avait très peu d'approximation et de choses non portables. On sait maintenant que tu faisais référence à un autre tutorial...
D'ailleurs, je ne vois pas en quoi le tuto a besoin de savoir que les entiers sont sur 32 bits.
C'est exactement mon point.
- double ça permet de stocker des nombres décimaux
Et alors ? quel est véritablement le problème, le terme "décimaux" n'est pas approprié, rien de plus. Dans la pratique c'est souvent comme ça et tout le monde comprend de quoi il s'agit.
K&R définit un float ainsi :
---------------------- by contrast with float, which means floating point, i.e., numbers that may have a fractional part. ----------------------
Il n'est pas précisé qu'elle est décimale... et c'est bien! La plupart des problèmes que rencontrent les débutants -- et des moins débutants aussi -- avec les flottants sont dus au fait que les flottants ne sont pas décimaux. Le plus navrant, c'est qu'ils en concluent qu'il s'agit de problème de précision (ce qui est faux, c'est un probléme de quantification).
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, 15:09, candide wrote:
C'est simple, dans K&R, une bibliothèque est une virtualité c'est quelque chose qui existe mais qui n'est pas tangible. D'ailleurs expliquent-t-ils seulement ce qu'est une bibliothèque (en général, p as la bibliothèque standard), je vérifierai.
Effectivement, K&R ne définit pas précisément ce qu'est une bibliothèque au point qu'on pourrait penser que bibliothèque = bibliothèque standard. J'ai fait la recherche des 94 occurrences de "library" dans le texte, j'ai seulement trouvé ceci :
----------------------- Finally, getch and ungetch go into a fourth file, getch.c; we separate them from the others because they would come from a separately- compiled library in a realistic program. -----------------------
On pourra lire aussi les deux extraits suivants :
--------------------- main will usually call other functions to help perform its job, some that you wrote, and others from libraries that are provided for you. --------------------- (le bouquet, c'est que le lecteur apprend ça au tout début (1er paragraphe, 1er chapitre))
et
--------------------- Source files may be compiled separately and loaded together, along with previously compiled functions from libraries ---------------------
ce qui est extrêmement mystérieux (quand on ne connait pas) surtout qu'il n'a pas expliqué ce qu'est la compilation séparée et d'ailleurs, je me demande même si l'ouvrage s'abaisse à expliquer ce que c'est.
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.
On 9 mar, 15:09, candide <c-cand...@wanadoo.fr> wrote:
C'est simple, dans K&R, une bibliothèque est une virtualité c'est
quelque chose qui existe mais qui n'est pas tangible. D'ailleurs
expliquent-t-ils seulement ce qu'est une bibliothèque (en général, p as
la bibliothèque standard), je vérifierai.
Effectivement, K&R ne définit pas précisément ce qu'est une
bibliothèque au point qu'on pourrait penser que bibliothèque =
bibliothèque standard. J'ai fait la recherche des 94 occurrences de
"library" dans le texte, j'ai seulement trouvé ceci :
-----------------------
Finally, getch and ungetch go into a fourth file, getch.c; we separate
them from the others because they would come from a separately-
compiled library in a realistic program.
-----------------------
On pourra lire aussi les deux extraits suivants :
---------------------
main will usually call other functions to help perform its job, some
that you wrote, and others from libraries that are provided for you.
---------------------
(le bouquet, c'est que le lecteur apprend ça au tout début (1er
paragraphe, 1er chapitre))
et
---------------------
Source files may be compiled separately and loaded together, along
with previously compiled functions from libraries
---------------------
ce qui est extrêmement mystérieux (quand on ne connait pas) surtout
qu'il n'a pas expliqué ce qu'est la compilation séparée et d'ailleurs,
je me demande même si l'ouvrage s'abaisse à expliquer ce que c'est.
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.
C'est simple, dans K&R, une bibliothèque est une virtualité c'est quelque chose qui existe mais qui n'est pas tangible. D'ailleurs expliquent-t-ils seulement ce qu'est une bibliothèque (en général, p as la bibliothèque standard), je vérifierai.
Effectivement, K&R ne définit pas précisément ce qu'est une bibliothèque au point qu'on pourrait penser que bibliothèque = bibliothèque standard. J'ai fait la recherche des 94 occurrences de "library" dans le texte, j'ai seulement trouvé ceci :
----------------------- Finally, getch and ungetch go into a fourth file, getch.c; we separate them from the others because they would come from a separately- compiled library in a realistic program. -----------------------
On pourra lire aussi les deux extraits suivants :
--------------------- main will usually call other functions to help perform its job, some that you wrote, and others from libraries that are provided for you. --------------------- (le bouquet, c'est que le lecteur apprend ça au tout début (1er paragraphe, 1er chapitre))
et
--------------------- Source files may be compiled separately and loaded together, along with previously compiled functions from libraries ---------------------
ce qui est extrêmement mystérieux (quand on ne connait pas) surtout qu'il n'a pas expliqué ce qu'est la compilation séparée et d'ailleurs, je me demande même si l'ouvrage s'abaisse à expliquer ce que c'est.
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.
