Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Quel tutoriel pour débuter ?

202 réponses
Avatar
Migrec
Bonjour,

Je cherche un tutoriel imprimable sur le web pour apprendre le C avant
d'acheter un bouquin "de référence".
Je suis débutant en programmation mais je connais les scripts shell
(linux), le HTML ou encore un peu de PHP.

Quel tutoriel imprimable me conseillez-vous pour débuter ? Les 560 pages
de celui du site du zéro
(http://www.siteduzero.com/tuto-29-8-0-apprenez-a-programmer-en-c.html)
découragent un peu mon imprimante, même avec le recto-verso
automatique... Mais le style me plaît ! Existe-t-il quelque chose dans
le même esprit mais en plus condensé ?

--
Migrec

10 réponses

Avatar
Marc Boyer
On 2008-08-27, candide wrote:
Marc Boyer a écrit :
Après quelques années de recherche, en effet, j'ai finis par
trouver uniquement 5 bouquins
"C Programming -- A modern approach" pour débuter



Pour débuter et même aller plus loin.

K&R 2d pour continuer



Incontournable mais apporte bien peu par rapport à une lecture complète
du précédent.



Oui, mais c'est bien de varier les sources. Et puis tellement
de monde se réfère à ce bouquin que si l'on s'intéresse au langage
C, il faut y jeter un oeil.

Harbison & Steele pour consolider



Livre très mauvais selon moi. Jargoneux et mal organisé et contenant
beaucoup d'erreurs (consulter l'impressionnant errata).

Tiens hier soir, je cherchais à m'informer sur les "trap
représentations", je vais dans l'index, je cherche "trap" : rien. A
"representation" dans l'index, aucun renvoi vers "trap" alors que cette
notion est vraiment importante et nouvelle en C99.
En principe la notion devrait être développée dans le chapitre 6,
intitulé "Conversions an representations" [qu'il aurait d'ailleurs fallu
appeler "Representations and Conversions" puisque -- et c'est logique --
leur exposé commence par les /representations/ pour se poursuivre avec
les /conversions/]. je parcours tout le § 6.1 sur les representations et
je ne vois rien sur les /traps/, bref, à l'heure actuelle, e ne sais pas
où ils en parle dans leur livre.
Et ça se prétend un livre de référence (c'est le sous-titre) et en plus
à la 5ème édition ! je rigole. Les auteurs connaissent peut-être le C
mais ils ne savent pas écrire un livre clair et organisé



Le détail de tes critiques est juste, mais je suis plus indulgent
sur le jugement global. A chacun de se faire une opinion. Disons
qu'entre "C programming" et la norme, il y a de la place, et que ce
bouquin et à ma connaissance le meilleur/moins pire sur ce créneau.

C unsleashe pour en ajouter



Non, livre très surfait, les trois-quarts de l'ouvrage (que dis-je, les
4/5 voire les 9/10) sont un affreux hors-sujet, par contre un tas de
questions très intéressantes ont été ignorées.



Hors sujet ? Quel serait le sujet ? Ce sont des retours d'expérience
de pros sur le C. Ca ne présente pas le C en lui même, mais son
utilisation pratique. Bon, oui, je pense que si j'étais l'éditeur en
chef, je virerais une moitié des chapitres, et je recalerais pas
mal de code.
Il manque aussi pas mal de chose à mon gout sur les tests, les
preconditions, etc.
Mais sur ces 1300 pages, il y en a quand même 300-600 de bonnes.

La norme....



ben un excellent document, souvent lisible malgré ce qu'on dit (même si
je trouverais quand même aussi pas mal à redire mais il est possible que
je n'ai pas le niveau pour tout comprendre), des exemples assez souvent
bien choisis. Au moins eux (les auteurs) ils donnent des définitions des
notions qu'ils étudient.



Tout à fait.
Mais on y apprend pas à programmer.

Tu oublies un excellent livre, le meilleur selon moi :

Plauger, "The C standard library".



Pas sous la main.

Le problème des bouquins/tutoriels faciles et faux, c'est
qu'ils sont gentils avec le débutant (c'est facile) mais
qu'il risque de se rendre compte après qu'une partie de ce
qu'il croit juste ne l'est pas.



La gamme des documents dont tu parles est tellement large qu'on ne peut
parler en généralité.

Comment jugeriez vous un professeur chinois de langue
française qui expliquerait que le français, c'est
facile, et qu'il n'y a que 2 groupes de conjugaisons
des verbes ?



Tu caricatures. Je ne serais pas choqué qu'on fasse _comme si_ il n'y
avait que des verbes du premier groupe pour expliquer ce que c'est que
le passé simple en français et mieux le distinguer du passé composé. Que
fera l'auteur lambda d'un cours de C confronté à la même tâche (je vais
caricaturer moi aussi) : il va t'enseigner d'abord toutes les formes
conjuguées à tous les groupes et à tous les temps en dérivant au passage
sur la notion collatérale de préfixe, suffixe et infixe puis il va
traiter du passé simple vs le passé composé en prenant des exemples dans
toute la gamme de ce qu'il a déjà expliqué, histoire de bien surcharger.



Et ben voilà. Moi qui enseignait le C (j'arrête cette année), je
disais bien que je présentais "un sous ensemble", que j'avais
choisi comme étant utilisable et à peu près cohérent, et que sur
certains points, je mentionnais que c'est compliqué, que l'on a
pas besoin de voir les détails dans des travaux scolaires, mais
que dans un cadre pro, il faudrait aller creuser les détails.

Il y a un juste milieu je pense entre dire toute la vérité
(et noyer les débutants) ou mentir: préciser qu'on ne dit pas
tout, que les détails sont compliqués, et que ce sont les
détails qui font que les codes plantent (et que ça peut couter
cher, genre un satellite ou une fusée...)

Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Avatar
Marc Boyer
On 2008-08-27, LMC wrote:
Bonsoir,
Je ne me vois pas lire un livre pour experts (K&R) alors que je débute et de
plus en anglais.



Le K&R n'est pas un livre pour expert: il a des qualités et des
défauts, mais il se veut être un bouquin pour débutant en C
(mais pas pour débutant en programmation).
De plus, il a été traduit en français.

Non, ce livre n'est pas de Delannoy. Il s'agit d'un livre édité par
MicroApplication dont le copyright date de 1997 mais achevé d'imprimer en
juillet 1998. Ce livre vient de Data Becker Gmbh & Co KG, auteur Gerhard
Willms.



Inconnu au bataillon.

Voilà, je vais vous laisser sur cette situation. Je continue mon étude avec
les 2 et jusqu'à ce jour, cela fonctionne bien.



Bien sur que "jusqu'à ce jour, cela fonctionne bien"... En
informatique, faire un code de 400 lignes qui marche deux jours sur
la machine du développeur, ce n'est pas très compliqué. Et C n'est
pas forcément le meilleur outil pour faire cela.
La question, c'est: "est-ce que j'apprend aujourd'hui me servira
dans 5 ans?".

Je suis aux saisies formatées de nombres octaux et hexadécimaux.



Pas vraiment une notion essentielle.

Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Avatar
LMC
Bonjour,
Je ne tiens pas à poursuivre indéfiniment ce reportage. lol
Je suis le livre, un point c'est tout. Après quand j'aurai un peu plus de
connaissances, je serai à même de juger le pour et le contre.
La vie n'est pas parfaite et la perfection n'existe pas, alors faisons avec
ce que nous trouvons.
Encore merci pour ton aide et intervention.
Je suis encore ce fil pour tenter de voir ce que cela donne.

--
@++
LMC
"candide" a écrit dans le message de news:
48b59962$0$12027$
LMC a écrit :
Il s'agit d'un livre édité par MicroApplication dont le copyright date de
1997 mais achevé d'imprimer en juillet 1998. Ce livre vient de Data
Becker Gmbh & Co KG, auteur Gerhard Willms.



OK, je ne connais pas.

Voilà, je vais vous laisser sur cette situation. Je continue mon étude
avec les 2 et jusqu'à ce jour, cela fonctionne bien. Je suis aux saisies
formatées de nombres octaux et hexadécimaux.



Les nombres ne sont ni octaux ni hexadécimaux, c'est leur représentation
mathématique qui l'est. Bon sinon, les saisies formatées en octal et en
hexa !!! mais le débutant s'en fout et ça lui sert à rien pour apprendre
le C, c'est que de la prise de tête, ça oblige en plus à connaître pas mal
de choses alors qu'on peut faire plein de choses amusantes et
intéressantes sans connaître ça.



Avatar
LMC
Bonjour,
Alors, bon amusement. lol
Ah, j'allais oublié, il ne faut pas dire je veux car cela ne se fait pas. De
toute façon, vouloir oupas vouloir, cela ne change rien, la nature a
toujours le dernier mot.rotfl

--
@++
LMC
"candide" a écrit dans le message de news:
48b5cc4a$0$26841$
Thierry B. a écrit :


Justement, le débutant a parfois envie de comprendre, et ce genre



Mais il même essentiel qu'il comprenne. Le tout est que les choses soient
faites dans le bon ordre.

d'exercice est formateur: il faut lire la doc des fonctions de la
bibliothèque, se bagarrer avec les chaines de caractères, plein de
trucs, quoi.



Bref pour toi apprendre est un combat, une lutte. Pour moi, apprendre
c'est comme quand je vais au cinéma ou quand on me raconte une histoire ou
que je fais un voyage. En tous cas, c'est comme ça que je veux que ce
soit.






Avatar
LMC
Bonjour,
Dénigrer ne sert à rien. Cela ne fait pas avancer quoi que ce soit.
Le livre est inconnu dans ton bataillon, pourtant je l'ai bien devant moi,
il n'est pas illusion !
Ce que tu as appris à l'école, cela te sert-il encore ? Peut-être bien que
oui, peut-être bien que non. Cela n'a pas d'importance de le savoir. Ce qui
importe c'est le résultat : l'ouverture de l'esprit. Le reste suivra. On ne
met pas la charrue avant les boeufs ! La maison se construit brique par
brique !
Je continue mon étude.

--
@++
LMC
"Marc Boyer" a écrit dans le message
de news:
On 2008-08-27, LMC wrote:
Bonsoir,
Je ne me vois pas lire un livre pour experts (K&R) alors que je débute et
de
plus en anglais.



Le K&R n'est pas un livre pour expert: il a des qualités et des
défauts, mais il se veut être un bouquin pour débutant en C
(mais pas pour débutant en programmation).
De plus, il a été traduit en français.

Non, ce livre n'est pas de Delannoy. Il s'agit d'un livre édité par
MicroApplication dont le copyright date de 1997 mais achevé d'imprimer en
juillet 1998. Ce livre vient de Data Becker Gmbh & Co KG, auteur Gerhard
Willms.



Inconnu au bataillon.

Voilà, je vais vous laisser sur cette situation. Je continue mon étude
avec
les 2 et jusqu'à ce jour, cela fonctionne bien.



Bien sur que "jusqu'à ce jour, cela fonctionne bien"... En
informatique, faire un code de 400 lignes qui marche deux jours sur
la machine du développeur, ce n'est pas très compliqué. Et C n'est
pas forcément le meilleur outil pour faire cela.
La question, c'est: "est-ce que j'apprend aujourd'hui me servira
dans 5 ans?".

Je suis aux saisies formatées de nombres octaux et hexadécimaux.



Pas vraiment une notion essentielle.

Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)



Avatar
Marc Boyer
On 2008-08-28, LMC wrote:
Bonjour,
Dénigrer ne sert à rien.



Oui, mais critiquer est utile.
Est-ce dénigrer ou critiquer que dire qu'un bouquin
est plein d'erreurs ?

Le livre est inconnu dans ton bataillon, pourtant je l'ai bien devant moi,
il n'est pas illusion !



Je n'ai jamais dit le contraire.

Ce que tu as appris à l'école, cela te sert-il encore ?



Tout, non (mais on s'en doutais), mais une bonne
partie oui. Et une grande majorité de ce que j'ai appris
entre mon BAC+3 - BAC+5.

Ce qui importe c'est le résultat : l'ouverture de l'esprit. Le reste suivra.



Peut importe si la fusé explose à condition de savoir apprendre
de ses erreurs ? Ben non, ce genre de raisonnement est vrai à l'école,
peut-être vrai à titre individuel, mais dans le monde professionnel,
l'ouverture d'esprit ne suffit pas.

On ne met pas la charrue avant les boeufs ! La maison se construit brique par
brique !



Oui, mais quand les fondations sont mauvaises, et qu'on s'en apperçoit
1 an après, c'est un peu génant...

Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Avatar
Marc Boyer
On 2008-08-27, candide wrote:
BOn, je préviens tout de suite que les les deux livres de Delannoy dont
tu parles, à savoir :

(i) Programmer en Langage C, Eyrolles (1997),
(ii) Le livre du C premier langage, Eyrolles (1994 & 2002),

sont pour moi de mauvais livres d'un point de vue de la qualité
pédagogique et je ne les connais que très mal.



Tout pareil pour moi ;-)

Pareil pour ses
"Exercices en Langage C". Moi, le livre de Delannoy auquel je me réfère
est le suivant

(iii) Claude Delannoy, "Langage C", Eyrolles (1999 & 2002), 920 pages.



Pas lu.

Marc Boyer a écrit :

Prenons "Programmer en langage C avec exercices corrigés",
édition de 1997, Eyrolle, §1.1
main(){
...
}
Tiens, pas de type de retour de main...




Oui, pour moi c'est inexcusable en effet. Dans son livre "Langage C", on
trouve aussi de tels exemples d'emploi de main() à de nombreuses
reprises. C'est d'autant plus étonnant que l'auteur dit lui-même, pages
820-821 :

"[L'en-tête de la fonction main()] ne peut toutefois s'écrire que sous
l'une des deux formes suivantes, la seconde étant indispensable
lorsqu'on souhaite récupérer les informations fournies par l'environnement :

int main(void) /* forme usuelle */
int main(int nbarg, char *argv[]);"

Et il ajoute, ce qui est contestable :

"on rencontre souvent des formes différentes, théoriquement hors norme :

main() /* théoriquement hors norme mais généralement accepté */
int main() /* théoriquement hors norme mais généralement accepté */

ces en-têtes sont cependant acceptés par toutes les implémentations,
quitte à provoquer un message d'avertissement (warning)."

Néanmoins, pour me faire l'avocat du diable, voici le /hello word/ de K&R2 :

------------------------------ 8<-----------------------------------
In C, the program to print ``hello, world'' is
#include <stdio.h>
main()
{
printf("hello, worldn");
}
------------------------------ >8 -----------------------------------



Oui, ça ne leur rend pas honneur.

Je passe sur l'indentation étrange de l'exemple du §1.9

if (op == '+') printf("leur somme est : %d", n1+n2) ;
else printf("leur produit est : %d", n1+n2) ;



Bon OK, mais ça c'est une question de style,



Hein ? C'est quoi ce style ? Rien n'est aligné.

le tout est d'être constant
dans ces choix (je n'ai pas vérifié en l'espèce).



Ca l'est pas, je te rassure.

liste chainée. Déjà, pas de type liste, on manipule
directement les chainons. Mais surtout, dans tous les
exos corrigés, on a un seul malloc (solution de l'exo 11.1)
qui fait un cast (transtypage) de la valeur de retour,
et pas de test de la valeur de retour de malloc.
La page avant, pas de test de valeur de retour de fopen...
Pas un seul free, pas un seul realloc dans les exemples...




Oui, pas terrible en effet. Je vérifie dans son bouquin (iii) cité
ci-dessus où il y a un chapitre complet là-dessus : il teste bien
malloc() dans ses exemples, il libère, il donne un exemple de realloc.
Au passage, j'ai noté que dans ce même chapitre, son traitement des
listes chaînées est beaucoup trop succint. Dans ses "Exercices corrigés
en langage C", il teste le retour de fopen().



OK

Aller, un autre bouquin: "Le livre du C premier langage"



Bon,je répète ce bouquin est particulièrement indigent.

dont des pages sont dispos en ligne. Le choix de présenter
le "switch" comme un complément en fin de livre et non
avec les structures de controle de base me semble discutable.



Bon, ça c'est un partie pris pédagogique qui me semble en effet
discutable mais bon, c'est le libre arbitre de l'enseignant.



Admettons.

(...) Et sur la page 4, la déclaration
de la fonction cube dans le main (plutôt vieux jeu comme façon
de coder).



OK et dans son livre (iii) il utilise occasionnelement ce genre de
déclarations. T'as pas un autre argument que "vieux jeu" ?



C'est une mauvaise habitude que de déclarer soit même les entêtes
dans le code utilisateur et non dans le code qui définit. Quitte
à le faire, autant le faire en dehors du main, le passage au .h
sera plus "naturel" à mon sens.


Sur la page 2 du chapitre sur les variables, il pourrait quand même
mentionner les identifiants valides mais réservés (ou faire une note
de bas de page disant que çaa existe).



OK mais c'est censé être un livre (je te cite le sous-titre) "pour les
vrais débutants en programmation". Le débutant il va jamais penser à écrire

int __toto;

donc ça c'est pas très grave, dans un premier temps.



Si, si, justement.
Le débutant, il va regarder les docs, et il va voir que pleins
de types dans les docs standart finissent par _t, donc, il va faire
pareil. La encore, on peut ne pas mettre toutes les infos, mais
mentionner que certains identifiants sont réservés (et renvoyer
soit à une annexe du bouquin, soit au chapitre de la norme).

Page 15, il explique que
"le code dit ASCII (abréviation de American Standard Code for
Information Interchange) a tendance à se généraliser." (ce qui
en 2008 me laisse pantois)



Tu penses à quoi ? UTF-8 ?



Je pense qu'en 2008, les jeux de caractères, c'est la merde, et
que le "sous-ensemble" ASCII est la norme de fait, mais que dès
que tu attaques les caractères entre 128 et 255, c'est la merde.
Moi, je préviens dans mon cours que quand on débute, on évite
les accents, les cédilles, et on se limite à a-z,A-Z,0-9, et les
trucs pas trops exotiques.


Bon, un texte ascii qui passe en UTF-8, ça ne
se voit pas, non ? Et puis au moins, il parle du jeu de caractères, tu
as plein de livres qui laissent penser que le seul jeu de caractères est
l'ascii sans même le citer. Par ailleurs, l'affirmation de Delannoy est
reprise par exemple dans le livre de King (§ 7.3 Character Types) :

"Todays' most popular character set is ASCII."



Oui, pour un américain c'est acceptable: ils ne savent pas qu'il
existe autre chose ;-) Pour un français, qui en plus met des 'ç'
dans ses exemples...

Tous les exemples dans K&R sont en ascii, même si les auteurs précisent
bien que c'est propre à ce jeu de caractères.

Les jeux de caractères européens contiennent l'ascii, difficile
d'échapper à l'ascii-centrisme.



Heureusement.

Donc je ne suis pas du tout choqué par cela dans une première approche.



Moi non plus, si on précise que la réalité est plus complexe !

Quand aux "conversions
non dégradantes" entre int et float, là aussi, ça m'amuserait
de voir ce que signifie "non dégradante" pour
float f= INT_MAX - 7;



Effectivement, ça manque de précautions de contexte mais quand on
s'adresse à des débutants, il faut passer outre ce genre de détail,



Non ! On peut dire que c'est compliqué, que ça marche bien
avec les petites valeurs, que pour le débutant, ça ne pose
quasiment jamais de problèmes, mais qu'il peut y avoir des
problèmes aux limites.

Pas besoin d'aller super dans les détails: tiens,
je donne un exemple simple: faire le calcul n * 1/n
en utilisant une boucle, pour des valeurs de n entre
1 et 10.

for(int n= 1; n< ; n++){
double somme=0.0;
for(int i= 0; i < n ; i++){
somme+= 1.0 / (double) n;
}
if (somme == 1.0){
printf("Pour n=%d, somme exacten", n);
} else {
printf("Pour n=%d somme-1.0=%fn", n, somme-1.0);
}
}

Puis remplacer %f par %e

Ca suffit à marquer les débutants et à comprendre que
tout n'est pas si simple.

Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Avatar
candide
Marc Boyer a écrit :

Pas besoin d'aller super dans les détails: tiens,
je donne un exemple simple: faire le calcul n * 1/n
en utilisant une boucle, pour des valeurs de n entre
1 et 10.

for(int n= 1; n< ; n++){
double somme=0.0;
for(int i= 0; i < n ; i++){
somme+= 1.0 / (double) n;
}
if (somme == 1.0){
printf("Pour n=%d, somme exacten", n);
} else {
printf("Pour n=%d somme-1.0=%fn", n, somme-1.0);
}
}

Puis remplacer %f par %e



Le programme suivant :

#include <stdio.h>

int main(void)
{
int n, i;

for (n = 1; n <= 10; n++)
{
double somme = 0.0;

for (i = 0; i < n; i++)
{
somme += 1.0 / (double) n;
}

if (somme == 1.0)
{
printf("Pour n=%d, somme exacten", n);
}
else
{
printf("Pour n=%d somme-1.0=%f tt(%%f)n", n, somme - 1.0);
printf("Pour n=%d somme-1.0=%e t(%%e)n", n, somme - 1.0);
}
}

return 0;
}


donne ceci chez moi :


Pour n=1, somme exacte
Pour n=2, somme exacte
Pour n=3, somme exacte
Pour n=4, somme exacte
Pour n=5 somme-1.0=-0.000000 (%f)
Pour n=5 somme-1.0=-1.110223e-16 (%e)
Pour n=6 somme-1.0=-0.000000 (%f)
Pour n=6 somme-1.0=-1.110223e-16 (%e)
Pour n=7, somme exacte
Pour n=8, somme exacte
Pour n=9 somme-1.0=0.000000 (%f)
Pour n=9 somme-1.0=2.220446e-16 (%e)
Pour n somme-1.0=-0.000000 (%f)
Pour n somme-1.0=-1.110223e-16 (%e)



Ca suffit à marquer les débutants et à comprendre que
tout n'est pas si simple.



OK. Mais je dirais "tout n'est pas si simple avec les flottants" (en
particulier, tester une égalité de flottants après avoir fait des
opérations qui conduisent àd es erreurs d'arrondis est quand même
douteux). Le comportement qui peut sembler surprenant ici (_pourquoi_ la
somme est considérée comme exacte pour n=7 et pas pour n=6 ? ce qui
m'échappe à vrai dire) n'est pas véritablement du ressort du langage C.
D'ailleurs, ne se peut-il pas que le programme ci-dessus exécuté sur une
autre machine donne des résultats différents ?

Faut dire que je connais rien aux flottants en général (j'aime pas
l'approximation ;) ) va falloir que je m'y mette sérieusement un de ces
quatre !
Avatar
Marc Boyer
On 2008-08-28, candide wrote:
[SNIP code]
donne ceci chez moi :


Pour n=1, somme exacte
Pour n=2, somme exacte
Pour n=3, somme exacte
Pour n=4, somme exacte
Pour n=5 somme-1.0=-0.000000 (%f)
Pour n=5 somme-1.0=-1.110223e-16 (%e)
Pour n=6 somme-1.0=-0.000000 (%f)
Pour n=6 somme-1.0=-1.110223e-16 (%e)
Pour n=7, somme exacte
Pour n=8, somme exacte
Pour n=9 somme-1.0=0.000000 (%f)
Pour n=9 somme-1.0=2.220446e-16 (%e)
Pour n somme-1.0=-0.000000 (%f)
Pour n somme-1.0=-1.110223e-16 (%e)



Marrant: chez moi, seuls 7 et 10 ne donnent pas
de somme exacte. J'ai une Linux/gcc avec un x86
(Pentium 4...)

Ca suffit à marquer les débutants et à comprendre que
tout n'est pas si simple.



OK. Mais je dirais "tout n'est pas si simple avec les flottants" (en
particulier, tester une égalité de flottants après avoir fait des
opérations qui conduisent àd es erreurs d'arrondis est quand même
douteux).



En général, le débutant (habitué au décimal) ne comprend pas que
la machine ne sache pas représenter 0,1.

Le comportement qui peut sembler surprenant ici (_pourquoi_ la
somme est considérée comme exacte pour n=7 et pas pour n=6 ? ce qui
m'échappe à vrai dire) n'est pas véritablement du ressort du langage C.



Mais l'encodage des caractères n'est pas non plus véritablement du
ressort du langage C, mais il faut bien se le coltiner pourtant.

D'ailleurs, ne se peut-il pas que le programme ci-dessus exécuté sur une
autre machine donne des résultats différents ?



Si, sur la mienne, qui n'a rien de très exotique.

Faut dire que je connais rien aux flottants en général (j'aime pas
l'approximation ;) ) va falloir que je m'y mette sérieusement un de ces
quatre !



Personne ne peut savoir tout sur tout. Mais savoir quelles sont
les limites de ses compétences, c'est essentiel (et pas nouveau...).
C'est ça que je reproche à de nombreux bouquins: se ne sont pas
les approximations, mais de ne pas dire qu'elles en sont.

Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Avatar
Antoine Leca
En news:48b5aff8$0$16021$, candide écrivit:
Tu oublies un excellent livre, le meilleur selon moi :
Plauger, "The C standard library".



Existe en français (/La bibliothèque C standard/, Masson, Paris 1995, ISBN :
2-2258-4710-X), malheureusement référencé comme « indisponible »...
http://www.amazon.fr/exec/obidos/ASIN/222584710X/
http://www.eyrolles.com/Informatique/Livre/9782225847103/livre-la-bibliotheque-c-standard.php

C'est certainement très intéressant pour un implémenteur, raison pour
laquelle je l'ai acheté (il y a longtemps).
Pour un utilisateur je ne sais pas trop, il est vrai qu'il y a pas mal de
conseils très intéressants sur les points de détail de l'utilisation des
fonctions, mais il y a aussi des discussions trèèès longues sur des sujets
qui ont passablement vieilli, comme les adaptations locales. La partie
mathématique ne remplacera pas un ouvrage spécialisé sur ce sujet (et là je
suis sûr qu'il y en a plusieurs, peut-être plus orienté Fortran que C), même
s'il ne me semble pas au non-spécialiste que je suis que le livre de
Plaugher présente d'erreur.

Par ailleurs il fournit une traduction en français de la partie 7 de la
norme ISO de 1990, ce qui n'est pas rien.



Comment jugeriez vous un professeur chinois de langue
française qui expliquerait que le français, c'est
facile, et qu'il n'y a que 2 groupes de conjugaisons
des verbes ?



Tu caricatures.



À peine.

Les grammairiens ont décidé (sûrement depuis très longtemps) qu'il y avait
trois groupes, le premier (clair pour tout le monde), le deuxième (moins
évident) et tout le reste dans le troisième groupe.
En catalan, on a aussi trois groupes (respectivement le 1er comme le 1er du
français, le 3e correspond au 2e et le 2e au 3e), mais _tous_ les verbes
en -ir vont dans le 3e groupe, donc il y a deux conjugaisons pour le 3e
groupe, celle (dite incoative, avec le -isc-/-ix-/-iss- intercalé) qui
correspond au 2e groupe français, et celle (dite pure) qui correspond aux
verbes du 3e groupe français genre sentir ou venir. Les grammairiens ont ici
fait un choix différent.

Maintenant, là où c'est drôle, c'est lorsqu'on trouve (facilement) des
explications pour dire aux débutants qu'en français le 1er groupe ce sont
les verbes en -er, le 2e groupe les verbes en -ir, et le 3e groupe les
autres : autrement dit, ce sont les règles utilisées par la grammaire
catalane, mais elles ne correspondent que grossièrement à la réalité de la
Grammaire française (officielle, celle avec un G).

Et si tu groupes les deux dernières catégories ci-dessus, tu obtiens la
phraséologie du professeur de chinois de Marc...



le passé simple en français et mieux le distinguer du passé composé.



Le passé simple en français, pour moi c'est comme les définitions de
fonctions style K&R (sans prototypes) en C : un débutant en est
(consciement) sevré.

Et l'exemple est frappant : je suis des rares personnes qui utilisent un
passé simple en entête de citation, et qui utilise des définitions genre K&R
dans mes programmes (si je dois les compiler sur de vieux compilateurs).
Mais je suis parfaitement conscient que c'est un comportement suranné.


Antoine