Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Oui il y a des "projets" qu'on peut considérer de "classiques" car ils sont très interessants pour l'apprentissage, c'est le cas d'un annuaire, avec recherche dans un arbre binaire + listes chainées
Ou la programmation d'un tétris, qui en plus est vraiment sympa à faire !
C'est une voie plaisante d'apprendre le C, après faut quand même fouiller un peu pour comprendre comment ça marche ( pas évident l'algo d'effacement d'un element dans un arbre binaire + liste chainée... )
Oui et avec tout ca, tu peut aussi en prime faire un programme de gestion de CD Audio, DVD, VHS, etc...
Mon Site
L'imagination est plus importante que le savoir. A. Einstein
Je ne répond à aucune question technique par MP, merci d'avance !
Soit dit en passant et pour en revenir au probleme initial, ca me surprend que personne n ai pense a guider notre queteur de manuels pour bien commencer vers la section tutoriels de ce site...
Pour certains d entre eux, ils permettent de partir de pas grand chose et de faire un rapide tour d'horizon du C.
C'est ce que j ai utilise pour me rafraichir la memoire apres deux ans de Java, et ca reprend vraiment tout depuis les bases.
Il y a vraiment des bons tutos...
Et pour continuer sur la discussion en cours, la prog systeme juste apres avoir fait les bases est effectivement un super exercice. Si on a un peu de temps et une grosse motivation, j ai trouve que le meilleur exercice etait de recoder morceau par morceau un shell unix... (si on aime Unix, bien entendu
En ce qui concerne le K & R, c'est une reference mais c'est a eviter pour un debutant... Ca avance trop vite a mon avis. Faut s'accrocher....
Pourquoi pas les livres de ...
Personellement, je préfére que tu achete un livre de C/C++ de CLAUDE DELANNOY, c'est un bon auteur, ses cours sont trés complets, et voila quelque titres :
- Programmer avec C
Programmer avec C++
Exercice corrigé de C
Merci, en même temps n'oublie pas les tutoriaux en ligne, ce son très interessant.
Re: Pourquoi pas les livres de ...
Malheureusement, et comme dans la majorité des livres de C, bourré de mauvaises pratiques...Envoyé par ccensam
Pour ma part,je me suis initié au C avec le cours de F.Faber disponible sur developpez.Il y a certes des mauvaises pratiques (comme dirait Emmanuel
mais il y a aussi de nombreux exercices corrigés à la fin de chaque chapitre et qui sont aussi interessant de point de vue algorithmique(plusieurs methodes de tri,....).
Voilà pour mon experience personnelle.
Salut,
Personnellement je te conseille le Kernighan & Ritchie.
Peut etre un peu corcé au début mais après quelques heures passées dessus ça commence à rentrer
Bon courage
J'hésitais à choisir un livre concernant le langage C.Oui, ce livre a l'air tout à fait prometteur. Je vais m'en procurer un dès que possible... Interessant par son coté C99 et POSIX.
Celui que je viens d'acheter (il y'a 2 jours) s'intitule "Méthodologie de la programmation en C, norme C99 - API Posix", 4ème édition (année 2005).
Je ne cherchais pas un livre pour débuter, mais plutot un livre de référence, et un livre de référence "d'actualité" (car des livres sur le langage C j'en ai, mais au mieux ils se référent de la norme "C89").
Je l'ai feuilleté pendant au moins une bonne heure à la FNAC, et je suis tombé sous "le charme".
Enfin un livre qui ne se repose pas sur l'utilisation d'un compilateur propriétaire genre Borland (TM) ou Microsoft (TM) (veuillez ne pas le prendre comme un appel au troll mais une simple observation de ma part concernant les livres d'apprentissage sur le langage C), mais sur l'utilisation d'un compilateur issu du monde du libre,ici GNU CC.
Bien que l'auteur parle des logiciels issus du monde libre, l'ensemble du livre (exception faite pour le chapitre 7 intitulé "L'API POSIX") ne fait référence à aucune plateforme particulière, donc utilisable que l'on soit sous Linux, Windows ou autre, et quelque soit le compilateur utilisé (à condition que celui-ci soit à la "norme", et plus particulièrement la C99)
L'auteur insiste sur les règles de présentation du code source (Découpage des lignes et indentation).et sur l'utilisation du Makefile, (même avec des exemples triviaux), encourage l'élimination du moindre message d'avertissement du compilateur et préconise l'utilisation des options d'avertissements de celui-ci (du genre : -W -Wall -std=c99)
Le plus important concernant ce livre selon moi, est qu'il fait réfrence à la norme C99, tout est présenté (type caractère, type entier, type entier étendu, type caractère large, type booléen, type complexe flottant, etc...)
Ce livre dispose d'un mémento des fonctions et macrofonctions de la bibliothèque standard, très bien présenté, on y trouvera : le prototype, le ou les entêtes standard à inclure, une brève description du traitement effectué et le cas échéant des notifications d'erreurs et des renvois à des entrées similaires.
Cerise sur le gateau : un excellent chapitre sur la modularisation des programme en C (passe en revue plusieurs approches permettant d'y parvenir).
Ce livre est parfaitement abordable pour un débutant selon moi, tellement la présentation et le vocabulaire sont limpides (je crois que je vais aimer Latex
Je n'ai pas encore terminé le livre (à peine commencé), mais d'avance j'ai la conviction que celui-ci marquera les esprits.
Par habitude j'evite les livres dépassant les 500 pages (merci les indigestions), mais celui-ci (faisant à peu près 650 pages) passera tout seul.
Seul point négatif : la couverture me semble un peu légère à mon goût pour un livre de ce poids (une couverture rigide aurait été la bienvenue), je l'ai donc renforcé en le recouvrant avec du film plastique transparent "spécial livre".
Re: Pourquoi pas les livres de ...
Par curiosite, quel genre de pratiques qualifies-tu de "mauvaises" ?
Re: Pourquoi pas les livres de ...
Oh bah c pas dur tu connais pas emmanuel j'ai regardé un livre de M.Delannoy l'autre jour: pas de fflush() une utilisation de scanf() à tout va. Comme dirait l'autre problèmes de saisie:Par curiosite, quel genre de pratiques qualifies-tu de "mauvaises" ?
http://emmanuel-delahaye.developpez....tes.htm#saisie
http://emmanuel-delahaye.developpez....#fflush_stdout
Moi je ne connais pas la norme par coeur mais je suis sur qu'on peut trouver d'autres petites choses. Ceci dit le critiquer comme cela ne fait pas avancer les choses: ces livres étant les moins chers, souvent c'est ceux la qui sont choisis. Non il faudrait que certains l'aident en reprenant les codes et en relisant ces livres avec lui. L'ennui c'est que bcp de ces "certains" critiquent mais au moment d'aider nont "plus le temps" ou "y'a le K&R et tellement d'autres livres..." dommage!
Ceci dit, je pense que Mr Delannoy peut accepter quelques critiques avec l'argent que son livre a dû lui procurer : ce serait je pense plutôt à lui de faire l'effort de faire évoluer son livre, en se documentant un peu mieux.
Je ne critique pas le livre ou le niveau pédagogique de son oeuvre loin de là, ayant lu quelques chapitres j'ai d'ailleurs trouvé que le livre pouvait permettre de comprendre progressivement les concepts fondamentaux, mais par ailleurs je pense juste que quand on fait une action commerciale comme celle de publier un livre sur un domaine technique pointu comme le C, on doit être capable de faire profiter à ses lecteurs des évolutions de la matière en question; ne serait-ce pas un comble que des "bénévoles" viennent aider une action commerciale tout en enrichissant les personnes concernées ? enfin à mon avis il y aurait un problème... Après on est pas forcément d'accord avec moi
Yes. I agree.
Le langage evolue. Mais si la maniere de l'enseigner n'evolue pas, ca ne sert pas a grand chose.
Par exemple : j'ai ete surpris d'apprendre que gets() est 'deprecated' depuis 1989... Ca souleve un vrai probleme.
C'est même pire que ça. gets() est un bug depuis sa création...
Ne penses-tu pas que du fait que gets ne fasse pas la vérification par rapport à un size défini, la fonction soit plus rapide que fgets par exemple ?
Je pense que dans certains cas, où la vérification est déjà faite en amon par exemple, où quand on est sûr de la taille du flux on peut utiliser gets.. Mais je vais me faire taper sur les doigts je suis sûr !!
- Comment faire la vérification en amont ?
- Que signifie concrètement "quand on est sûr de la taille du flux". En fait, c'est une question de ligne. Un singe tapant sur le clavier ne s'embarasse pas de ces détails... Sous Linux, le buffer d'entrée (stdin) peut avoir une taille de plusieurs Mo. C'est programmable.
- Quel intérêt de chercher de la vitesse pour une saisie utilisateur ? Quand on a redirigé en provenance d'un fichier ? Ok. La sécurité a un coût.
Le problème du gets() est un 'dead horse'. Il est scellé depuis plus de 15 ans.
"Utilisation initerdite dans les nouveaux projets."
Tiens moi cela me fait penser à de bons vieux souvenir lorsque j'étais étudiant en Info à l'IUT.
Lorsque l'on devait rendre un programme (quelque soit la taille ou l'importance de celui-ci), la toute première chose que faisait le professeur, était de vérifier que la saisie utilisateur est bien gérée.
Pour cela il tapait n'importe quoi (chiffres, carractères alphanumérique, symbole etc..) et de taille différente afin de déterminer la réaction du programme.
L'une des premières règle que les profs en Info nous faisait bien comprendre est qu'il ne fallait jamais faire de suppositions sur ce que l'utilisateur saisira au clavier, et ils nous recommandaient même de faire comme si l'utilisateur était un "singe" assis derrière le clavier.
Oui, ma remarque ne s'appliquait pas au flux stdin classique ( clavier ) mais plutot à un flux stdin redirigé, par exemple à partir d'un fichier dont on connait la taille, mais oublions
Merciiiiiiii Emmanuel !
Grâce à toi, j'ai trouvé le picto que j'utiliserai dans la documentation technique d'une appli pour définir les utilisateurs !
Trop cool
morte de rire, moi aussi je pique l'image...
ceci dit, mes profs ont effectivement commencé par me répéter n-fois qu'il fallait supposer que l'utilisateur allait faire toutes les bourdes possibles, donc je suis ok avec Emmanuel Delahaye mais je comprends le point de vue de KiLVaiDeN.
je porte (enfin j'essai de porter) une application compilée sous HP-UX avec c89 sur Linux avec gcc et je me rends bien compte des horreurs qu'on peut écrire sans se poser la question de savoir si telle ou telle fonction fait partie de telle ou telle norme...m'enfin, heureusement -Wall est là, ainsi que vousPar exemple : j'ai ete surpris d'apprendre que gets() est 'deprecated' depuis 1989... Ca souleve un vrai probleme.
cordialement,
jula.
Répondre avec citation
Partager