Langage C : cours + exercices corrigés + TPs + exams

Timon a écrit:...
Comme vous le savez, Internet et les librairies regorgent de livres abordant l'apprentissage du langage C. Malheureusement, bon nombre de ces cours/tutoriels sont de mauvaise qualité.
Exemple de mauvais tutoriel :
Langage C de Patrick Trau
Exemple de mauvais livre :
La bible du programmeur de Kris Jamsa et Lars Klander

Par "mauvaise qualité", j'entends méconnaissance du langage (de sa norme) et enseignement à partir de ces mauvaises bases. J'ai souvent l'impression que leur(s) auteur(s) l'ont appris par empirisme. Bien sûr qu'il faut manipuler le langage pour le comprendre mais il ne faut pas s'arrêter à ça si on veut l'utiliser concrètement et surtout si on veut l'enseigner !
Ainsi, on y voit des absurdités qui pourraient être facilement corrigées si l'auteur avait été un peu sérieux :

Patrick Trau a écrit:Fonctions d'entrées/sorties les plus utilisées
[...]
char putchar(char)

Alors que

La norme (C89) a écrit:4.9.7.9 The putchar function

Synopsis

Code:

 #include
int putchar(int c);

L'erreur peut sembler minime. Pourtant, c'est une fonction que tout programmeur connaît. Comment peut-on se permettre une telle erreur qui amènera le débutant forcément dans un mur ?
Ce n'est pas la seule erreur, sinon elle serait plus ou moins pardonnable (faute de frappe, copié-collé, distraction ?).
...

Partrick Trau a écrit:

Code:

premier=(struct page *)malloc(sizeof(struct page));

Code:

premier = malloc(sizeof(struct page));

Code:

premier = malloc(sizeof *premier);

Code:

premier=(struct page *)malloc(sizeof(struct page));
puts("entrez votre premier entier");
scanf("%d",&premier->val);

Code:

premier = malloc(sizeof *premier);

methodiX a écrit:Je ne suis pas sûr que c'est la meilleure façon pour allouer de l'espace à un pointeur de type (struct page*) !!! Même si le transtypage est implicite, il est préférable à mon avis de le mettre en évidence, même pour avoir un code plus lisible, surtout si on se contente de mettre sizeof *premier au lieu de sizeof(struct page) ...

Code:

int malloc(int n_bytes);

nabiL a écrit:Vraiment bravo pour la qualité de la discussion. Très intéressante pour ceux qui ont un niveau confirmé en C.

mosa a écrit:

nabiL a écrit:Vraiment bravo pour la qualité de la discussion. Très intéressante pour ceux qui ont un niveau confirmé en C.

malheureusement, ce n'est pas le cas pour moi.

manianis a écrit:Le problème d'allocation/libération de la mémoire est un sujet trés important. Il n'est pas traité avec précision pour les non informaticiens vu les maux de tête qu'il puisse générer.

Timon a écrit:Pourtant, la règle est simple : pour chaque allocation sa libération.
Plus sérieusement, lors de l'écriture du Kit du Débutant, je me suis dit qu'il serait intéressant qu'il y ait justement une aide à ce sujet. C'est pourquoi, les fonctions d'allocation/libération sont "enroulées" dans de nouvelles fonctions qui vérifient, dans la mesure du possible, que le programmeur n'a rien fait de bizarre et rien oublié.

manianis a écrit:Aussi, les problèmes d'allocations et de libération de mémoire ne sont pas toujours la faute du programmeur mais aussi peuvent provenir d'une faute de conception.

manianis a écrit:Oui, justement, c'est trés simple à dire mais les exceptions sont multiples. Les bugs font que parfois des fonctions standard ne réagissent pas de la manière attendue et qu'il génèrent des problèmes de mémoire.

nabiL a écrit:Timon:
à votre avis, pourquoi fopen(NULL, NULL)n'est pas géré par certains compilateurs?

Peut-tu présenter en quelques mots la programmation défensive?

En effet, les implémenteurs de compilateurs ne sont pas obligés de gérer les cas comme fopen(NULL, NULL), malloc(0),

manianis a écrit:Timon :
Si les valeurs passées aux dites fonctions possèdent un type correct ou un type qui lui est compatible alors la ce n'est pas la tache du compilateur de vérifier la validité de ces valeurs.

Il n'est pas logique de faire des appels du type fopen(NULL, NULL). Le programmeur a commis une faute de conception. Je ne sais pas si peut être dé-référencer mais je sais qu'il a été déclaré comme un define. Et à ce que je sais il faudra pour le redéfinir faire appel à undef.

methodiX a écrit:Il y a les codes retour non? 0 si aucune erreur sinon le code de l'erreur.

C'est vrai il y a des fonctions qui retournent des valeurs entières non nulles par exemple "descripteur d'un fichier" ... dans ce cas, il faut gérer les erreurs autrement à mon avis.

manianis a écrit:Il n'est pas logique de faire des appels du type fopen(NULL, NULL). Le programmeur a commis une faute de conception.

Je ne sais pas si peut être dé-référencer mais je sais qu'il a été déclaré comme un define. Et à ce que je sais il faudra pour le redéfinir faire appel à undef.

manianis a écrit:Timon: Je ne sais pas si NULL peut être dé-référencé mais je sais qu'il a été
déclaré comme un define. Et à ce que je sais il faudra pour le
redéfinir faire appel à undef.