Suite à la discussion concernant l'état du cours C (Mise à jour du Cours), il serait utile de centraliser les remarques ainsi que les questions fréquentes dans un unique sujet.
Je vous invite donc à le faire vivre pour aider celui qui aura la tâche de s'attaquer à la refonte du cours. N'hésitez pas à laisser :
des remarques constructives sur le cours
des liens vers les sujets et erreurs soulevés fréquemment par les débutants suivant le cours
des points manquants que vous aimeriez y voir abordés
des points existants que vous aimeriez voir abordés plus tard
...
Pour éviter que ce sujet ne comporte trop de messages merci de vous limiter à des contributions uniquement (pas de messages d'encouragements par exemple).
Pour résumer, le public concerné irait du total newbie au deutant confirmé qui désirerait apprendre le C sur une des plateformes classiques windows/linux/mac. Le tuto devrait pouvoir fournir non seulement un minimum sur l'installation des outils, des rudiments de leur manipulation mais aussi une introduction facile au C. Il faudrait ensuite aborder succinctement quelques notions avancées pour passer relativement rapidement à l'introduction de la création d'une interface graphique, revenir à des notions plus poussées en C puis à des notions plus poussées en GUI. Le tout étant de savoir quoi mettre dans quoi.
Les outils
L'idéal serait évidemment d'avoir «la même chose» sur les 3 plateformes. Il y a plusieurs alternatives :
code blocks bien installé et bien configuré il fournit un bel ensemble. Apparemment il y a quelques difficultés sous mac.
atom/sublim text/ou équivalent nouvelle génération ils sont relativement complets, du moins facile à compléter (ligne de commande, gdb, makefiles, ..) l'approche sera plus orientée ligne de commande ; ok pour linux et mac mais il faudra choisir quelque chose pour windows comme msys/cygwin/bash par dfaut
une image d'un système linux minimal avec des outils préconfigurés l'idéal : tout le monde parle de la même chose et part avec les même outils. Idéal sans doute pour commencer mais les utilisateurs windows et mac seront un peu mis à l'écart ... il devront se débrouiller tous seuls pour leur configuration par la suite.
Introduction au C
L'intro devrait être basée sur (au minimum) C99 ou (idéalement) sur C11. On pourra y retrouver par exemple :
structure d'un programme (monofichier)
étape de la compilation (rudimentaire)
exemple avec utilisation direct du debuger
survol des contôles de flux
présentation rapide de la libc, du préprocesseur
explication type natif, variables avec une mention spéciale sur les strings (?)
introduction aux fonctions
agrégation de types simples dans des structures
les tableaux
première approche des pointeurs
utilisation makefile / bibliothèque tierce
Introduction GUI
La SDL2 semble être préférée car le débutant plus ou moins confirmé peut vite s'éclater à faire des trucs sympas. Faire deux «parties» une concernant le «jeu» avec SDL2 (ou allegro ?) une autre plus «classique» pour les applications «bureau» avec GTK+/QT/wxWindows ? Il faudrait un personne qui s'y connaisse mieux que moi pour essayer de faire un petit plan.
C avancé
les fichiers
pointeurs avancés
cast et compagnie
union
conception et modularité (survol)
strings (avancé) unicode(?)
GUI avancé
id. Into GUI
Vers l'infini et au-delà
Cette partie ne concerne pas directement un tuto d'apprentissage du C mais contient des notions pouvant faire l'objet d'autres tutos
utiliser un base de donnée
les threads
mieux programmer → conception et modélisation / algo / prouver ses programmes / assert / ...
Dans le cours C avec SDL il y a un défaut dans la gestion des évènements qui induit fréquemment les débutants dans l'erreur : il s'agit de l'absence de test du retour des fonctions SDL_WaitEvent() et SDL_PollEvent.
Il serait bien d'expliquer aussi pourquoi il est important de mettre SDL_PollEvent et le switch associé dans un bloc while{}.
Sinon, il faudrait répondre au moins aux posts qui apparaissent 2 fois par jour (j'exagère), genre pourquoi mon scanf() saute une fois sur deux.
Si je me réfère au bouquin issu du site (2nde impression, 2010), il serait probablement sage d'introduire aux fonctions AVANT le TP du plus ou moins, à l'aide du convertisseur F/€ (ou C°/F, moins préhistorique ^^) qui ne nécessite pas l'appui des pointeurs. Ce TP et ses améliorations sont déjà trop volumineux pour tout coller dans le main()
Actualiser un peu sur la norme :
for (int i=0; i<xx; i++)
/***VS***/
int i;
...
for(i=0; i<xx; i++)
...Un exemple parmi d'autres, les différentes formes du main en est un autre.
Ne pas hésiter à linker les autres tutos, notamment ceux vers lesquels nous envoyons régulièrement les gens, e.g. les events de Fvirtman pour le chapitre SDL, ou celui de Marc Mongenet sur les tables et pointeurs.
Il serait pas mal d'aborder d'autres notions (pointeurs sur fonctions, fichiers en binaire...) sans forcément s'y attarder et en faire un chapitre, mais au moins en évoquer l'existence, surtout lorsqu'il y a un tuto existant sur le site.
Également introduire un peu à la débrouillardise, comment on trouve une doc de lib sur gogole... Ptêt faire le tp du pendu en filant la doc de string.h, genre "à partir de la doc, trouvez comment faire une copie de chaine et trouver l'occurrence d'une lettre".
Dans les grandes lignes...
Bonne continuation.
Edit.
Un peu de méthode pour éviter les fonctions à 23 arguments ? Structures de structures, tables de structures etc..
Ah, le cours du C ! C'est lui qui m'a fait découvrir le site (et aimer ce langage qui me faisait peur...).
À mon avis il fait distinguer ce qui relève de la mise à jour et ce qui relève de compléments. La SDL 2, c'est une mise à jour ; les pointeurs sur fonction, c'est un complément. Il me semble qu'il s'agit ici de réfléchir à une mise à jour, non ?
Il faut aussi prendre une décision : C89 ou C99 (ou C11) ? Une mise à jour qui s'appuierait sur le C99 présenterait la nouvelle écriture du for, mais aussi d'autres choses. Et il faudrait commencer par expliquer qu'il existe un C plus ancien qui est légèrement différent, car je crois qu'on trouve encore des compilateurs qui font du C89 par défaut (il faut donc parler des options de compilation). Ne serait-ce pas plus simple de présenter le C89 et de finir par un chapitre introduisant le C99 ? (avec notamment l'option de compilation). (À titre personnel j'aimerais lire un cours qui s'appuie sur un C récent, vu que j'ai du mal à comprendre certaines nouveautés... Et puis ce serait probablement le premier du genre en français ‒ même le cours de Zeste de Savoir, qui est plus récent, s'appuie sur le C89.)
Je trouve excellente l'idée de drx d'introduire les fonctions plus tôt. Outre que ça évite d'avoir un "plus ou moins" à rallonge, ça permettrait aussi de laisser le lecteur recopier et utiliser une petite fonction vidant le buffer, parce qu'en effet les problèmes de scanf sont parmi les plus fréquents sur le forum. Bien sûr, il faudra dire au lecteur qu'on lui donnera les détails plus tard. D'ailleurs on pourrait lui dire quelque chose comme : « lorsqu'on saisit des données au clavier, elles sont momentanément stockées dans une mémoire-tampon ("buffer") et scanf pioche dedans ; mais parfois il peut rester des données dans le tampon, et alors elles seront lues au prochain appel de scanf à la place des données saisies par l'utilisateur, c'est pourquoi il est souvent nécessaire de vider ce tampon, et voici comment... » Bref, on ne rentre pas dans le détail du fonctionnement du "buffer", mais on peut quand même expliquer pourquoi il peut rester des trucs dedans (par exemple si l'utilisateur avait saisi deux nombres au lieu d'un seul, l'un des deux est resté dans le tampon, c'est lui qui sera lu la prochaine fois, pas besoin de détailler).
À mon avis il faut insister sur l'importance d'écrire des fonctions, et des fonctions qui soient courtes et consacrées à une tâche (une fonction pour ordonner le tableau, une autre fonction pour l'afficher). Je me permets de faire cette remarque parce que, ayant appris le C tout seul, au début je faisais des 'main' à rallonge et c'est en lisant le forum que, peu à peu, j'ai vraiment compris l'intérêt des fonctions. C'est pour ça que j'aime l'idée d'introduire les fonctions le plus tôt possible.
Au fait : quand on représente graphiquement une fonction, on dessine toujours une boîte avec des données qui entrent dans la boîte par la gauche et qui en sortent par la droite. C'est vrai que, en maths, on écrit f:E-->F, donc de la gauche vers la droite. Mais pour un cours de C, je pense qu'il faut aller dans l'autre sens. En effet, en C la syntaxe est la suivante :
sortie fonction(entrée) ;
Donc : F<--f(E)
Autre point : de nombreux cours, et je crois que c'est le cas de celui du site, disent qu'il faut utiliser %f pour écrire une variable de type double (avec printf), mais %lf pour la saisir (avec scanf). J'ai longtemps été dérouté par ça : zut, les formats de printf ne sont donc pas les mêmes que ceux de scanf, c'est bizarre. En fait pas du tout ! Il faut utiliser %lf dans les deux cas. Certes, %f marche aussi avec printf en raison d'une conversion implicite (mais pas avec scanf !), mais n'embrouillons pas les débutants avec ce genre de considération ! Un double, c'est %lf et basta !
Dernier point qui me vient à l'esprit : le cours actuel du C utilise systématiquement :
int main(int argc, char *argv[])
Je sais qu'il y a une explication à ça (qu'on utilise une écriture ou l'autre, ça ne change rien, donc gardons la deuxième car un jour elle nous servira), mais cette raison ne me convainc pas : je trouve que c'est embrouiller le lecteur que lui montrer un truc qu'il ne peut pas comprendre et qui ne lui servira pas avant la fin du cours. Personnellement, je déteste qu'on m'oblige à faire un truc sans m'expliquer pourquoi (« tu verras plus tard, c'est pour ton bien » --> suspect). Mais bon, mon cas personnel n'est peut-être pas significatif ?
Autre point : de nombreux cours, et je crois que c'est le cas de celui du site, disent qu'il faut utiliser %f pour écrire une variable de type double (avec printf), mais %lf pour la saisir (avec scanf). J'ai longtemps été dérouté par ça : zut, les formats de printf ne sont donc pas les mêmes que ceux de scanf, c'est bizarre. En fait pas du tout ! Il faut utiliser %lf dans les deux cas. Certes, %f marche aussi avec printf en raison d'une conversion implicite (mais pas avec scanf !), mais n'embrouillons pas les débutants avec ce genre de considération ! Un double, c'est %lf et basta !
Sauf erreur, ce n'est que depuis C99 que "%lf" est standardisé pour printf.
Perso il n'y a pas photo, la norme c'est C11 point, d'ici quelques années il va y avoir C2x donc pour un nouveau cours on oublie C89.
Cela semble évident. Dans un cours de mécanique auto, on apprendrait à monter un pneu sur une gente, pas à cercler une roue en bois.
Mais il faut donner conscience que le langage a évolué et qu'on peut croiser ou devoir gérer d'autres formes de code avec plus de restrictions comme le cas des déclarations en tête "warning : mix code"...
Mais également avertir sur les vices / risques de la norme actuelle, genre pourquoi mon VLA de 50Mo fait planter mon programme...
Après, peu de gens sont prêts à aller se farcir la norme, clairement, j'en suis et il est possible que je passe à côté de trucs intéressants. Inutile d'en faire trop. Perso, la différence entre entre vieille et nouvelle norme s'arrête aux déclarations à la volée et les VLA. Et je m'interdis les VLA. Par contre, les déclarations à la volée c'est du gain de lisibilité énorme.
Quelques autres points qui me sont venus en tête :
Il faudrait probablement dans le chapitre sur les pointeurs, parler du cast, et expliquer ce qu'est un déréférencement. En tout cas, un peu de vocabulaire / glossaire, et pas que sur les pointeurs. Beaucoup de nouveaux ne connaissent pas certains termes qu'on utilise dans nos réponses à leurs questions. Surtout quand ce sont des têtes qui répondent et ont tendance à être technique.
Peut-être proposer en correction, en plus d'une solution pour "débutant", un code un peu moins naïf histoire de montrer un peu ce qu'est l'efficacité sans pour autant faire de l'obfuscation. Pas facile de savoir où est la limite, je sais, mais quand-même.
Introduire la base de la base : l'algèbre de Bool.
Un peu de construction, comme factoriser le code, genre pourquoi on ne fait pas un plus ou moins 2 joueurs dans 2 grands case copiés /collés en remplaçant juste le "rand()" par "puts("Joueur 1, entrez un nombre :"); scanf("%d", &nbrMyst);"
Perso, la différence entre entre vieille et nouvelle norme s'arrête aux déclarations à la volée et les VLA. Et je m'interdis les VLA. Par contre, les déclarations à la volée c'est du gain de lisibilité énorme.
Il faudrait probablement dans le chapitre sur les pointeurs, parler du cast.
Il y a aussi les commentaires // comme différence importante à partir de C99.
Pour le cast, je ne pense pas qu'il faille attendre les pointeurs. C'est un simple opérateur présentable dès qu'on a expliqué qu'en C, toute valeur a un type.
pour ma part je trouverai intéressant d'avoir une chapitre consacré à la conception de makefile . Et pour la partie sur la SDL j'aurai bien voulu avoir une indication sur la façon de link avec codeblock ( genre -lSDLmain -lSDL ) .
Et pour la partie sur la SDL j'aurai bien voulu avoir une indication sur la façon de link avec codeblock ( genre -lSDLmain -lSDL ) .
Supprimer codeblocks serait vraiment cool aussi. C'est quand même un trés vieux IDE, qui n'est plus du tout maintenue. Quitte à refaire des screenshots et réécrire des guides de setups, autant orienter le lecteur vers des IDE en vogues (car plus de réponses potentiels à leurs questions sur le forum).
Si debugger, c’est supprimer des bugs, alors programmer ne peut être que les ajouter - Edsger Dijkstra
Sauf que des IDE sur linux à part codeblock je vois pas . Faudrait une alternative comme vim/emacs , ni'mporte + console explicité dans le futur cour .
Sauf que des IDE sur linux à part codeblock je vois pas . Faudrait une alternative comme vim/emacs , ni'mporte + console explicité dans le futur cour .
Il faut peut être commencer par définir le périmètre du projet, car en l'occurrence, il y a déjà de la matière à faire plusieurs tutos !
Les outils
Donc pour l'absolute beginner il faudrait un tuto d'installation d'au moins un outil. Il sera dans l'idéal multi plateforme, minimum windows/linux/mac. codeblocks est utilisé pour l'instant et semble remplir les conditions d'un outil pour débutant pour autant qu'il soit bien configuré ; @damjuve : il est toujours maintenu, la dernière version stable date d'il y a un an. En alternative on pourrait penser à atom/sublime text, ou à défaut eclipse, emacs, … mais ces derniers sont un peu trop techies.
Évidemment dans l'idéal cet EDI devra supporter un mode debug facile à appréhender et à introduire dès le départ. Il intégrera aussi facilement le compilo et les autres outils qui vont avec.
Le langage
Je suppose qu'une approche classique est recommandée. Et les discussions vont bon train. Apprendre le langage, àmha, implique de ne pas aborder des sujets comme la SDL ou autres bibliothèques tierces. Se limiter aux fondamentaux me semble raisonnable. Reste le point des saisies, mais bon.
La conception / la modularité
mouais ... perso je ne sais pas comment l'aborder.
La chaîne de compilation / le modèle mémoire en C
surement à aborder aussi
Une FAQ
Devrait faire une page à part, pas même un sujet épinglé.
....
First solve the problem. Then, write the code. ~ John Johnson
L'IDE doit 1° exister sous Linux, Mac et Windows, 2° être gratuit et 3° facile à utiliser. Code::Blocks répond à ces contraintes. Pas vim par exemple (trop compliqué pour un débutant ‒ je sais, j'ai essayé), pas même Emacs à mon avis (que j'ai utilisé lors de mes études). Sublime Text n'est-il pas payant ? (Je ne sais pas.)
Je trouve que le gros point fort du cours original de M. Nebra, c'est la SDL : ainsi on pouvait apprendre le C et écrire de petits programmes amusants (au lieu de se limiter à la console), ce qui est motivant. D'ailleurs il me semble que c'est quelque chose qu'on retrouve dans tous les cours de programmation du Zéro, c'est pour ainsi dire la marque de fabrique de la collection (en plus du ton). Un cours de C sans la SDL perdrait cette originalité, ce serait un cours comme un autre, à quoi bon ?
Un cours de C sans la SDL perdrait cette originalité, ce serait un cours comme un autre, à quoi bon ?
Le problème c'est les débutants qui se jettent sur le graphique sans bases réelles sur le langage C lui-même. Un post récent montrait un débutant en C et en SDL qui posait une question sur une fonction qu'il a commise possédant 23 paramètres, sans compter les questions récurrentes sur «pourquoi ma variable change ?» lorsqu'on renvoie une variable locale ...
L'audience d'un tel cours doit être définie.
First solve the problem. Then, write the code. ~ John Johnson
Effectivement xD . Sinon pour la partie motivante du cour les activité comme le jeux du plus ou moins . C'est réellement motivant à mon goût de se faire noter/commenter sa fait ambiance de classe . En plus on peut pas être tenté de regarder la correction ,et une fois posté on a la chance de pouvoir tester d'autres version implémenter différemment . (Mieux que les "TP" en somme)
Est-ce la mise à jour du cours de M. Nebra, ou bien est-ce un tout nouveau cours ? (Cette question me semble primordiale.)
Est-il destiné à remplacer le cours de M. Nebra, ou bien à le compléter, ou encore à proposer deux cours très différents ? (Je trouverais judicieux de séparer les cours en deux catégories : les cours destinés aux pros, pour OpenClassrooms, et les cours destinés aux « zéros », pour la partie ancienne du site.)
Est-il destiné à des « zéros » ou bien à de futurs informaticiens ?
Le problème c'est les débutants qui se jettent sur le graphique sans bases réelles sur le langage C lui-même.
C'est en forgeant qu'on devient forgeron. Apprendre à manipuler des fonctions peut se faire dans un contexte de manipulation de tableaux, ou dans un contexte de calculs mathématiques, ou pourquoi pas dans un contexte d'utilisation de la SDL.
Et je rajoute un truc à propos de la programmation graphique. Je ne sais pas qui sera visé par la refonte du cours, mais si parmi les personnes visées, il y a des « programmeurs du dimanche » comme moi, je crois qu'il faut de la programmation graphique. Car en console on est très vite limité. Un « plus ou moins », un pendu, pourquoi pas un morpion tant que vous y êtes... Avec la programmation graphique, le nombre de possibilités de s'amuser explose. Tiens, hier soir il n'y avait rien à la télé, devinez quoi : j'ai écrit un petit programme qui affiche des courbes y=f(x), comme sur les calculatrices graphiques (avec Allegro). Bon, il faut le recompiler chaque fois qu'on change la fonction, mais ça m'a amusé (je sais maintenant à quoi ressemble sin 1/x ). Tous mes projets nécessitent de la programmation graphique. Sans programmation graphique, les gens qui programment pour se divertir risquent de vite laisser tomber. Je suis persuadé que le succès des cours du site du Zéro vient en grande partie du fait qu'ils introduisent la programmation graphique. Faire des petits jeux avec la SDL, ça donne envie de s'accrocher ! Alors que trier des tableaux...
C'est en forgeant qu'on devient forgeron. Apprendre à manipuler des fonctions peut se faire dans un contexte de manipulation de tableaux, ou dans un contexte de calculs mathématiques, ou pourquoi pas dans un contexte d'utilisation de la SDL.
Je pourrais presque être d’accord. Le problème c’est que certains débutants sautent des pans entiers de cours pour aller voir la partie SDL. Sinon +1 au reste de ton message.
Sinon, un point qui n’a pas encore été soulevé est le manque d’exercices sur certaines notions. Rajouter des exercices à la fin de chaque chapitre peut être une bonne chose.
@PicoDev : ce serait cool de mettre à jour le premier post de temps en temps histoire de faire apparaître ce qu’il doit y avoir dans le nouveau cours, en gros, ce sur quoi tout le monde ici est à peu près d’accord :
Est-ce la mise à jour du cours de M. Nebra, ou bien est-ce un tout nouveau cours ? (Cette question me semble primordiale.)
Est-il destiné à remplacer le cours de M. Nebra, ou bien à le compléter, ou encore à proposer deux cours très différents ? (Je trouverais judicieux de séparer les cours en deux catégories : les cours destinés aux pros, pour OpenClassrooms, et les cours destinés aux « zéros », pour la partie ancienne du site.)
Je suppose que c'est à M. Nebra de décider, tout va dépendre des moyens qui seront mis en œuvre … On peut aussi imaginer créer un cours «collégial» sous licence libre à décider qui serait hébergé sur OC, mais là aussi M. Nebra décide. Un point à éclaircir avec OC.
Mais bon, vu l'état du cours et de ce qu'on récupère comme débutants qui s'y frottent, l'option refaire from scratch est à envisager sérieusement.
robun a écrit:
Est-il destiné à des « zéros » ou bien à de futurs informaticiens ?
Tout dépend aussi de M.Nebra, bien scinder serait à mon avis une bonne chose, quelque chose du genre
j'installe et je découvre un peu les outils
je commence un peu le C
je découvre le debuger
je commence des notions avancées
j'essaie le côté graphique
5 points avec + ou - 4 niveaux.
yo@n97one a écrit:
@PicoDev : ce serait cool de mettre à jour le premier post de temps en temps histoire de faire apparaître ce qu’il doit y avoir dans le nouveau cours, en gros, ce sur quoi tout le monde ici est à peu près d’accord :
fonctions ;
gestion erreurs ;
liens vers les autres tutoriels ;
etc.
Ouais mais pas avant ce WE ^_^ une mise à jour pour dimanche soir semble réalisable.
First solve the problem. Then, write the code. ~ John Johnson
J'ai découvert la programmation avec ce livre, comme beaucoup et c'est un peu ce livre qui a décidé de mon orientation concernant mes études malgré tout et avec le recul je pense que les points suivants seraient souhaitables:
Il manque une partie sur les operateurs bitwise,
la fonction strlen faite maison n'est pas un exemple de simplicité, le pendu peut-être écrit plus proprement,
il n'est fait nul mention de realloc, calloc dans la partie sur l'allocation dynamique,
usages de int à la place de size_t pour itérer sur un tableau, une chaîne de caractère... bof
mentionner rapidement comment un programme est organisé (les différents segments, a minima au moins mentionner le stack et le heap)
indiquer que même si ce n'est pas obligatoire, écrire le code en anglais est souvent standard
une partie sur les algorithmes serait souhaitable, de même que la récursivité n'est jamais abordé dans le cours
évidemment une MAJ de la partie SDL
la partie sur les pointeurs est bien trop courte, l'excellent "understanding and using c pointers" traite le sujet en plus de 200 pages, il y a matière à écrire
dans la partie "avancée", parler des appels systèmes fork(), exec(), des pipes avec à la clé un shell minimaliste à implémenter serait interessant
éventuellement une partie multithreading avec la bibliotheque pthread.
il n'est fait nul mention de realloc, calloc dans la partie sur l'allocation dynamique,
[...]
dans la partie "avancée", parler des appels systèmes fork(), exec(), des pipes avec à la clé un shell minimaliste à implémenter serait interessant
éventuellement une partie multithreading avec la bibliotheque pthread.
- Edité par VaultBoy il y a environ 5 heures
J'ai pas touche au C depuis des années, mais les points que tu soulèves ici posent a mon humble avis un problème de scope.
En effet, dans un cours a destination de débutants complets en programmation, il me semble hors propos de parler de la programmation système ou du multi threading. Après si on cherche a former de futurs informaticiens, alors la ça peut devenir cohérent mais je vois plutôt ça en deux cours distincts.
Je modérerais un peu le message de @Elried. Autant les problématique de fork, exec, et le multithreading sont effectivement des notions orthogonales qui méritent largement un autre cours (surtout pour le multithreading dans un langage comme le C ...). Autant les opérateurs bitwise et les usages des autres fonctions d'allocation sont des points importants.
Je vais pas vraiment revenir sur les points que je viens de mentionner comme ne devant pas aller dans un cours pour débutant. La raison est assez simple, rien que sur les notions de multi-threading, on pourrait en faire deux chapitres hyper longs et on n'aurait pas encore fait le tour des notions de base. Alors voir toutes les notions importantes et ce qui concerne le multiprocess ... Il y a largement de quoi avoir un cours dédié (et je parle même pas des problématiques de modèles mémoire faibles*).
* Aparté :
PicoDev a écrit:
La chaîne de compilation / le modèle mémoire en C
surement à aborder aussi
Avant que je comprenne de quoi tu parlais, j'ai vraiment cru que tu parlais du modèle mémoire de C et pas simplement de la différenciation entre pile et tas.
Fin de l'aparté.
En revanche voir les opérateurs bitwise est très intéressant, ça peut permettre de comprendre les systèmes de flags, mais encore bien plus important : on peut s'en servir pour introduire les représentations des données en mémoire au niveau du bit. Et ça pourrait éviter avec le temps la sempiternelle question "pourquoi mon réel il a pas du tout une précision infinie" (devine quoi : ta mémoire est finie). De même, les questions de réallocations sont importantes puisqu'elles font une piqûre de rappel sur la mémoire, mais calloc est plus importante encore : démarrer avec une mémoire initialisée.
En ce qui concerne la gestion des erreurs, oui, c'est revenu plusieurs fois. Cela dit, un vital ne me semble pas mentionné : la différence entre erreur de programmation et erreur due à l'environnement (contre laquelle on ne peut pas se prémunir). Les premières devraient être gérées par assertion, et les secondes par code de retour en C (et toute la joie que procure la gestion d'une erreur à tous les étages d'une pile d'appel).
Si on reçoit un pointeur NULL c'est une erreur de programmation, et elle ne devrait pas pouvoir apparaître dans un code qu'on a validé et ne devrait donc pas renvoyer un code d'erreur (que de toute façon on ne saurait pas gérer : le code est pété, ben ... OK, le code est pété, crash). D'ailleurs la définition de DNDEBUG permet la suppression de tous ces contrôles ou même éventuellement de redéfinir assert pour indiquer à l'utilisateur une erreur critique qui n'est pas de sont fait.
Finalement, en ce qui concerne la notion de fonction, un problème récurrent dans tous les cours (et là je ratisse hyper large, mais c'est un fait, c'est d'ailleurs particulièrement frappant dans les cours sur les langages OO), c'est l'absence de LA notion qui doit être comprise le plus tôt possible parce que c'est le coeur même pour bien organiser et développer : la notion d'API. Aucun cours n'insiste sur l'important de définir des abstractions pour les notions que l'on manipule et d'en cache les détails pour rendre leur usage plus facile. Je pense notamment à un schéma très commun en C : les types opaques. C'est absolument vital pour gagner en organisation et manipuler nos notions de manière bien plus sereine.
Je pense notamment au sempiternel double pointeur pour un tableau 2D, avec trouze mille allocations sans contrôles et des déréférencements à tord et à travers ... Quand une API avec littéralement 4 fonctions remplis le job sans effort avec une seule allocation ...
Fin bref, voilà pour ce qui me vient à l'esprit pour le moment.
Les débutants qui viennent poser des questions ont souvent des lacunes dans des notions fondamentales, mais pas très compliquées. Je pense notamment aux notions de mot clé, d'identificateur, d'expression, de portée, de passage de paramètre, d'initialisation.
Tiens, à propos d'initialisation, je crois qu'il y a souvent un malentendu avec :
int *pointeur = NULL ;
(Il me semble que c'est l'initialisation préconisée dans le cours du C.) Mais parfois, les gens croient que ça initialise la variable pointée. Alors que la variable pointée n'existe même pas.
Du coup je ne préconiserais pas ça. Si on veut s'obliger à toujours initialiser ses variables après la déclaration, est-ce qu'il ne vaudrait mieux pas présenter, plutôt, ce genre de chose ?
int valeurInitiale = 0 ;
int *pointeur1, *pointeur2, *pointeur3 ;
pointeur1 = pointeur2 = pointeur3 = &valeurInitiale ;
Pour ma part je ne vois pas l'intérêt d'une telle initialisation. Si on s'oblige à toujours initialiser ses variables après la déclaration, je ferais plutôt quelque chose comme ça :
Mais là les pointeurs ne sont plus initialisés, ils sont affectés. Au niveau syntaxe ça ne change pas grand chose pour des pointeurs, mais pour des tableaux et des structures, l'initialisation offre bien plus de possibilités que l'affectation.
Accessoirement, initialiser les trucs à 0 (que ce soit les pointeurs ou whatever), c'est pas une initialisation, c'est mettre une valeur au pif. Le but d'une initialisation à la base, c'est établir les invariants associés à la variable. Avec derrière une idée de "à partir de l'initialisation, ma valeur respecte telle propriété". Si on fait une initialisation au pif, ça devient "à partir de l'initialisation, ma valeur respecte telle propriété, enfin, sauf si on a pas encore fait la vraie initialisation, auquel cas c'est 0".
Personnellement je ne suis pas partisan d'initialiser systématiquement les variables, et je ne le fais pas (je ne fais que la « vraie » initialisation). Mais il me semble que c'était un parti-pris du cours du C, une sorte de sécurité (comme une bouée) pour être sûr de ne pas avoir de variables ayant une valeur indéterminée. Donc on l'initialise systématiquement à 0. Bon, pourquoi pas. Mais ce que je dis, c'est qu'alors il ne faut pas initialiser systématiquement un pointeur à NULL, car ce n'est pas vraiment la même chose et il me semble que ça prête à confusion (si j'en crois certaines discussions où les gens s'étonnent d'avoir une erreur de segmentation alors qu'ils ont « initialisé » le pointeur).
Après, le mieux est peut-être de ne pas imposer une initialisation systématique à 0 mais de faire quelque chose de plus intelligent au cas par cas.
Bonhomme !! | Jeu de plateforme : Prototype.
Bonhomme !! | Jeu de plateforme : Prototype.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C