Langage C : cours + exercices corrigés + TPs + exams
Forum INFOMATH :: Enseignement de l'informatique :: INFO - Supérieur (Etudiants et Professionnels) :: C/C++
Page 1 sur 2•
Page 1 sur 2 • 1, 2 
Langage C : cours + exercices corrigés + TPs + exams
C'est un cours complet avec des exercices corrigés, des TPs corrigés, et des exams:
Enjoy it
Enjoy it

lamia- Admin




- Messages : 1429
Inscrit le : 04 Nov 2007
Age : 22
Localisation : Tunis
Feuille de personnage
Capacité linguistique:


(996/1000)
manianis- Admin


- Messages : 976
Inscrit le : 10 Oct 2007
Localisation : Tunisie
Feuille de personnage
Capacité linguistique:


(999/1000)
Re: Langage C : cours + exercices corrigés + TPs + exams
100000 merci !!

chahrayar87- Nouveau membre




- Messages : 17
Inscrit le : 26 Déc 2007
Age : 21
Localisation : djerba-Nabeul
Feuille de personnage
Capacité linguistique:


(1000/1000)
Re: Langage C : cours + exercices corrigés + TPs + exams
Merci Lamia. Très active 
Sami - Methodix, tunis
Le génie de Newton a consisté à dire que la lune tombe alors que tout le monde voit bien qu'elle ne tombe pas.
(Paul Valéry)
Le génie de Newton a consisté à dire que la lune tombe alors que tout le monde voit bien qu'elle ne tombe pas.
(Paul Valéry)

methodiX- Admin


- Messages : 811
Inscrit le : 22 Mar 2007
Localisation : marsa - IPEST
Feuille de personnage
Capacité linguistique:


(1000/1000)
Re: Langage C : cours + exercices corrigés + TPs + exams
Bon faut tenir compte de quelques remarques ennocés par Timon dans ce sujet concernant ce site.
¤´¨)
¸.·´¸.·*´¨) ¸.·*¨)
(¸.·´ (¸.·`¤... Lamia
¸.·´¸.·*´¨) ¸.·*¨)
(¸.·´ (¸.·`¤... Lamia

lamia- Admin




- Messages : 1429
Inscrit le : 04 Nov 2007
Age : 22
Localisation : Tunis
Feuille de personnage
Capacité linguistique:


(996/1000)
Re: 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 queLa 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 ?).
...
¤´¨)
¸.·´¸.·*´¨) ¸.·*¨)
(¸.·´ (¸.·`¤... Lamia
¸.·´¸.·*´¨) ¸.·*¨)
(¸.·´ (¸.·`¤... Lamia

lamia- Admin




- Messages : 1429
Inscrit le : 04 Nov 2007
Age : 22
Localisation : Tunis
Feuille de personnage
Capacité linguistique:


(996/1000)
Re: Langage C : cours + exercices corrigés + TPs + exams
Je vais profiter du fait que ce sujet soit remonté pour développer ma critique ce "cours". Je vais prendre pour cible ses exercices corrigés et ne lister que ce qui me paraît le plus grave :
Non portabilité du code :
- Inclusion du fichier d'en-tête non standard alloc.h pour pouvoir utiliser malloc(). stdlib.h ne lui suffit pas ?
- Utilisation de la bibliothèque CONIO. Y a-t-il vraiment un intérêt à enseigner les bases du C avec ça ?
Transtypage du retour de malloc() :
Le transtypage ((struct page *)) n'est absolument pas utile et peut être dangereux puisqu'il bâillonnerait le compilateur en cas de non inclusion du fichier stdlib.h.
Enfin, je rappelle que le vrai prototype de malloc() est :
Or, void * se transtype implicitement en n'importe quel pointeur !
Bref, il pourrait s'épargner cette peine en écrivant simplement :
ou mieux :
Non vérification du retour de malloc() :
La mémoire est limitée et utilisée par d'autres programmes. L'allocation de mémoire peut donc échouer. Dans ce cas, la fonction renvoie NULL.
Utilisation de la fonction gets() :
Cette fonction est très bien... pour les pirates car elle leur ouvre les portes en grand. Il est vrai que sur la plupart des systèmes, il est maintenant plus difficile d'utiliser cette faille mais elle existe quand même.
Et même si on ne considère pas ce problème, il suffit seulement de se rappeler qu'elle ne fait aucun contrôle sur la longueur de la saisie. N'importe quel utilisateur peut faire planter le programme.
Il faut donc lui préférer fgets() qui permet de limiter la longueur de la saisie. Aucun risque de buffer overflow sauf si, bien sûr, vous utilisez mal la fonction.
Le plus étrange est que l'auteur cite cette fonction mais s'obstine pourtant à utiliser gets().
Enfin, utilisation de variables globales dans chacun de ses codes :
Il est important d'utiliser le moins possible les variables globales. En effet, plus le code évolue et plus il est difficile de connaître la valeur des variables globales.
On se retrouve alors avec des fonctions trop dépendantes les unes des autres et un code non (ou difficilement) réutilisable.
Il y a malheureusement d'autres choses qui ne sont pas correctes mais cela me semble suffisant pour vous dissuader de construire vos bases avec ce cours.
Non portabilité du code :
- Inclusion du fichier d'en-tête non standard alloc.h pour pouvoir utiliser malloc(). stdlib.h ne lui suffit pas ?
- Utilisation de la bibliothèque CONIO. Y a-t-il vraiment un intérêt à enseigner les bases du C avec ça ?
Transtypage du retour de malloc() :
Partrick Trau a écrit:
- Code:
premier=(struct page *)malloc(sizeof(struct page));
Le transtypage ((struct page *)) n'est absolument pas utile et peut être dangereux puisqu'il bâillonnerait le compilateur en cas de non inclusion du fichier stdlib.h.
Enfin, je rappelle que le vrai prototype de malloc() est :
- Code:
void *malloc(size_t n_bytes);
Or, void * se transtype implicitement en n'importe quel pointeur !
Bref, il pourrait s'épargner cette peine en écrivant simplement :
- Code:
premier = malloc(sizeof(struct page));
ou mieux :
- Code:
premier = malloc(sizeof *premier);
Non vérification du retour de malloc() :
- Code:
premier=(struct page *)malloc(sizeof(struct page));
puts("entrez votre premier entier");
scanf("%d",&premier->val);
La mémoire est limitée et utilisée par d'autres programmes. L'allocation de mémoire peut donc échouer. Dans ce cas, la fonction renvoie NULL.
Utilisation de la fonction gets() :
Cette fonction est très bien... pour les pirates car elle leur ouvre les portes en grand. Il est vrai que sur la plupart des systèmes, il est maintenant plus difficile d'utiliser cette faille mais elle existe quand même.
Et même si on ne considère pas ce problème, il suffit seulement de se rappeler qu'elle ne fait aucun contrôle sur la longueur de la saisie. N'importe quel utilisateur peut faire planter le programme.
Il faut donc lui préférer fgets() qui permet de limiter la longueur de la saisie. Aucun risque de buffer overflow sauf si, bien sûr, vous utilisez mal la fonction.
Le plus étrange est que l'auteur cite cette fonction mais s'obstine pourtant à utiliser gets().
Enfin, utilisation de variables globales dans chacun de ses codes :
Il est important d'utiliser le moins possible les variables globales. En effet, plus le code évolue et plus il est difficile de connaître la valeur des variables globales.
On se retrouve alors avec des fonctions trop dépendantes les unes des autres et un code non (ou difficilement) réutilisable.
Il y a malheureusement d'autres choses qui ne sont pas correctes mais cela me semble suffisant pour vous dissuader de construire vos bases avec ce cours.
Timon- Membre important


- Messages : 57
Inscrit le : 14 Jan 2008
Localisation : France
Feuille de personnage
Capacité linguistique:


(1000/1000)
Re: Langage C : cours + exercices corrigés + TPs + exams
Bravo pour les remarques pertinentes. Pourtant on nous a toujours conseillé de suivre ce cours. C'est vrai, pour débuter en C, il n'est pas très dangereux de suivre ce cours, puisqu'on ne s'aperçoit pas de ces fautes. Mais ça reste un très bon test pour les connaisseurs du langages C.
Sami - Methodix, tunis
Le génie de Newton a consisté à dire que la lune tombe alors que tout le monde voit bien qu'elle ne tombe pas.
(Paul Valéry)
Le génie de Newton a consisté à dire que la lune tombe alors que tout le monde voit bien qu'elle ne tombe pas.
(Paul Valéry)

methodiX- Admin


- Messages : 811
Inscrit le : 22 Mar 2007
Localisation : marsa - IPEST
Feuille de personnage
Capacité linguistique:


(1000/1000)
Re: Langage C : cours + exercices corrigés + TPs + exams
- Code:
premier = malloc(sizeof *premier);
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) ...
Sami - Methodix, tunis
Le génie de Newton a consisté à dire que la lune tombe alors que tout le monde voit bien qu'elle ne tombe pas.
(Paul Valéry)
Le génie de Newton a consisté à dire que la lune tombe alors que tout le monde voit bien qu'elle ne tombe pas.
(Paul Valéry)

methodiX- Admin


- Messages : 811
Inscrit le : 22 Mar 2007
Localisation : marsa - IPEST
Feuille de personnage
Capacité linguistique:


(1000/1000)
Re: Langage C : cours + exercices corrigés + TPs + exams
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) ...
C'est une méthode largement utilisée et qui est la plus maintenable.
Le problème du transtypage explicite du retour de malloc() est qu'il peut cacher des erreurs qui sont alors potentiellement dramatiques.
Si stdlib.h n'est pas inclus, malloc() n'est pas déclarée. Cependant, le compilateur peut émettre la supposition que la fonction est définie comme suit :
- Code:
int malloc(int n_bytes);
Ce qui est totalement faux dans notre cas. Normalement, le compilateur émet un avertissement pour indiquer que la fonction n'est pas explicitement déclarée et que son hypothèse est probablement fausse.
Cependant, le transtypage indique au compilateur : "Ne dis rien, je sais ce que je fais."
On n'est alors pas averti du problème et le programme rencontre un jour ou un autre un bug qui sera difficile à corriger.
Pour le reste, le transtypage ne doit pas avoir valeur de documentation, seulement de reconversion lorsqu'elle ne peut se faire naturellement. Ce document (en anglais) le démontre.
Revenons à sizeof *premier. premier est de type struct page *. Donc, lorsque ce pointeur pointe sur une adresse valide, *premier est l'élément qu'il pointe. Cet objet est de type struct page.
Le problème, pourrait-on objecter, est que premier ne pointe sur rien de valide avant l'appel de malloc(). Heureusement, la norme dit que l'expression sur laquelle on applique sizeof n'est pas évaluée. On détermine seulement le type de l'expression, d'où :
sizeof(struct page) = sizeof *premier = sizeof *premier++ = sizeof (*premier)++ = sizeof *(struct page *)NULL = ...
Timon- Membre important


- Messages : 57
Inscrit le : 14 Jan 2008
Localisation : France
Feuille de personnage
Capacité linguistique:


(1000/1000)
Re: Langage C : cours + exercices corrigés + TPs + exams
Vraiment bravo pour la qualité de la discussion. Très intéressante pour ceux qui ont un niveau confirmé en C.
Nabil - tunis
خير الناس أنفعهم للناس
خير الناس أنفعهم للناس

nabiL- Admin


- Messages : 1908
Inscrit le : 19 Mar 2007
Localisation : Tunisie
Feuille de personnage
Capacité linguistique:


(999/1000)
Re: Langage C : cours + exercices corrigés + TPs + exams
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.
mosa- Modérateur




- Messages : 636
Inscrit le : 11 Nov 2007
Age : 23
Localisation : los angeles
Feuille de personnage
Capacité linguistique:


(995/1000)
Re: Langage C : cours + exercices corrigés + TPs + exams
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.
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.
manianis- Admin


- Messages : 976
Inscrit le : 10 Oct 2007
Localisation : Tunisie
Feuille de personnage
Capacité linguistique:


(999/1000)
Re: Langage C : cours + exercices corrigés + TPs + exams
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.
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é.
Timon- Membre important


- Messages : 57
Inscrit le : 14 Jan 2008
Localisation : France
Feuille de personnage
Capacité linguistique:


(1000/1000)
Re: Langage C : cours + exercices corrigés + TPs + exams
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é.
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. J'ai eu par exemple ce type de problèmes avec quelques fonctions standard sous Visual C++, version 6.
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- Admin


- Messages : 976
Inscrit le : 10 Oct 2007
Localisation : Tunisie
Feuille de personnage
Capacité linguistique:


(999/1000)
Page 1 sur 2 • 1, 2 





