Le langage C

Bonjour à tous !

La beta du tutoriel a été mise à jour.

Merci pour vos relectures

• ajout d'un paragraphe au sujet des pointeurs de pointeur dans le chapitre sur les pointeurs ;
• refonte du chapitre sur les tableaux et fusion avec celui sur les tableaux multidimensionnels ;
• refonte du chapitre sur les chaînes de caractères et fusion avec celui présentant l'en-tête <string.h>.

Bonjour à tous !

La beta du tutoriel a été mise à jour.

Merci pour vos relectures

• déplacement de la partie concernant les représentations octales et hexadécimales à la fin du chapitre sur les variables ;
• suppression de l'extrait concernant les constantes prédéfinies du chapitre sur le préprocesseur ;
• refonte du chapitre sur l'allocation dynamique ;
• refonte du chapitre sur les fichiers ;
• suppression de la troisième partie du cours (son contenu étant désormais réparti entre le chapitre sur les chaînes de caractères et celui sur les fichiers) ;
• déplacement du chapitre sur la gestion d'erreur avant le chapitre sur le TP dans la première partie ;
• utilisation de printf() plutôt que de fprintf() jusqu'à sa présentation dans le chapitre sur les fichiers.

De manière générale, je n'ose pas trop commenter sur ce tuto, parce qu'il est régulièrement remanié de manière assez nette. Cependant, il semblerait que la première partie soit à peu près définitive, donc je me lance.

Je n'ai pas tout lu. Mais ma remarque porte sur l'organisation d'ensemble et plus spécifiquement sur la place du TP : il faut lire treize chapitres avant de commencer à faire quelque chose de ses mains. Treize !! J'ai trois remarques en fait.

1. J'ai bien conscience des impératifs de facilité et de faisabilité (je rédige un tuto sur l'assembleur, après tout ), mais soyons honnêtes, une calculatrice en notation polonaise inverse, c'est cliché, et c'est pas sexy du tout. Mais je n'ai pas d'idée meilleure à vous suggérer à brûle pourpoint, alors restons là-dessus.
2. Chacun de vos chapitres porte sur un type d'outils du langage C (les boucles, le préprocesseur, etc.) et s'efforce d'en traiter tous les aspects. À mon sens, c'est une erreur.
   1. Il y a bien la moitié des notions que vous abordez qui ne sont pas utilisées dans le TP. C'est autant d'information que le lecteur doit retenir sans pouvoir les fixer par une utilisation concrète.
   2. Quelques unes des choses que vous abordez n'ont tout simplement pas leur place dans une partie intitulée « Introduction ». Je veux dire, de toute mon expérience de codeur C amateur (ma connaissance du C correspond globalement au contenu de votre tuto, sauf les énumérations et unions), je n'ai absolument jamais fait usage de #elif. De même, je ne suis pas sûr d'avoir déjà eu besoin de do / while.
3. J'ai pleinement conscience que ce serait moche et mal codé, mais il est possible de réaliser le TP avec moins d'outils encore que ceux que vous utilisez. On peut se passer des fonctions, des blocs for et switch, de l'opérateur ternaire et de EXIT_FAILURE (d'autant que vous n'utilisez pas EXIT_SUCCESS) et donc de stdlib.h. On peut même pousser le vice jusqu'à virer le else if, puisque le if précédent se termine par un return.

Tout ça pour dire qu'il serait possible d'impliquer le lecteur beaucoup plus tôt dans le cours, à condition de totalement réorganiser celui-ci. L'idée étant de lui faire faire ce même TP sous une forme un peu dégueu, puis de le lui faire améliorer à mesure que de nouvelles notions sont introduites, pour finir quelques chapitres plus tard par un nouveau TP sur un sujet différent et qui mette en œuvre toutes les notions. Parce que si on réduit au strict minimum, il est possible de réussir ce TP en connaissant uniquement :

• les variables, leurs types et le cast ;
• les entrées / sorties ;
• la fonction main() et return ;
• les opérateurs numériques, bien sûr ;
• les test d'égalité / inégalité / supériorité et le bloc if ;
• les boucles while et le break.

La fonction pow() est donnée dans l'énoncé du TP et n'a donc pas à être connue. Mais ça implique d'avoir des chapitres qui abordent des outils appartenant à des catégories différentes, bien sûr. Du coup, il doit être possible de mettre les mains dans le cambouis pour autre chose qu'un exercice d'application au bout de seulement 5 ou 6 chapitres, ce qui me paraît plus profitable.

Bref, ce n'est bien évidemment qu'une suggestion.

Salut,

Tout d'abord, merci de ton retour.

La première partie est pour ainsi dire fixée en effet. C'est également le cas de la deuxième qui ne devrait sans doute plus que se voir ajouter deux chapitres : un sur la gestion d'erreur (encore) et un TP.

En effet, ce n'est pas un exercice original ni très attrayant. Toutefois, nous n'avons pas encore trouvé de meilleure suggestion.

Certes, cela est vrai. Cependant, c'est un des objectifs que nous nous sommes fixés en rédigeant le cours : être le plus exhaustif possible et éviter la dispertion des informations.

Pour ce qui est du préprocesseur, je suis d'accord avec toi, sa présentation aurait peut-être plutôt sa place dans la troisième partie du cours. Maintenant, cela suppose de ne pas non plus parler de la répartition en plusieurs fichiers dans la première partie (ce qui est tolérable, à mon avis).

En revanche, la boucle do … while me paraît avoir parfaitement sa place, il s'agit d'une structure de contrôle basique du langage qui est rencontrée assez fréquemment (mais moins souvent que les autres boucles).

Hmm… Et pourquoi ne pas prévoir deux TP dans la première partie ? Cela permettrait de maintenir l'actuel et de proposer un exercice supplémentaire plus tôt dans le cours. Le tout étant de trouver quel exercice en lieu et place du sempiternel « quel est l'âge du capitaine ? » qui implique en plus de présenter la génération aléatoire de nombres.

Sinon, concernant la macroconstante EXIT_FAILURE, celle-ci est impérative à partir du moment où la gestion d'erreur est réalisée. En effet, elle est la seule valeur portable permettant de signaler à l'environnement d'exécution un échec lors de l'exécution du programme. EXIT_SUCCESS n'existe en revanche que par symétrie, une valeur de zéro étant équivalente.

Certes, cela est vrai. Cependant, c'est un des objectifs que nous nous sommes fixés en rédigeant le cours : être le plus exhaustif possible et éviter la dispertion des informations.

Je peux comprendre la logique, mais je trouve que ça donne un résultat final qui tient plus de l'article encyclopédique que du cours à proprement parler.

Sinon, concernant la macroconstante EXIT_FAILURE, celle-ci est impérative à partir du moment où la gestion d'erreur est réalisée. En effet, elle est la seule valeur portable permettant de signaler à l'environnement d'exécution un échec lors de l'exécution du programme. EXIT_SUCCESS n'existe en revanche que par symétrie, une valeur de zéro étant équivalente.

À vrai dire, je vois plutôt ça comme une question de sémantique. Même si EXIT_SUCCESS = 0, tu ne transmets pas la même idée avec un return EXIT_SUCCESS qu'avec un return 0 : on peut envisager un programme de dézippage en ligne de commande qui retourne le nombre de fichiers extraits. Mais bon, c'est un détail, pas la peine de se prendre la tête avec ça.

Concernant le ou les TP, maintenant.

Sur le papier, rajouter un TP intermédiaire, ça sonne bien. Sauf que dans votre organisation actuelle, on ne peut guère l'introduire qu'après les chapitres 7, 9 ou 10. Dans les deux derniers cas, c'est trop proche du deuxième TP pour avoir du sens, donc reste le 7. Ça veut dire faire un exercice sans boucle et sans fonction, ce qui limite quand même beaucoup les possibilités.

La seule idée qui représente un tant soit peu un défi qui me vienne, c'est un calendrier perpétuel : l'utilisateur entre une date de la forme mm/jj/aaaa, et le programme lui donne le jour de la semaine correspondant. => il faut vérifier que la date a un sens, gérer les années bissextiles et le passage au calendrier grégorien. A priori, c'est faisable avec uniquement des conditions et des opérations mathématiques de base. Une variante serait un programme qui convertit une date d'un calendrier vers un autre (grégorien, hébreu, musulman, révolutionnaire, romain).

Ensuite, pour le TP final, celui qui doit mettre en jeu toutes les connaissances acquises dans la première partie, je pense qu'il serait plus intéressant de faire coder un jeu simple en ligne de commande (genre un morpion ou un puissance 4). Il pourrait y avoir plusieurs niveaux de difficulté de l'exercice : deux joueurs humains qui jouent l'un après l'autre (facile), le joueur contre la machine qui doit alors avoir une IA (difficile), les deux et le programme demande à chaque partie quel mode utiliser (overkill).

Dans les deux cas, ça simplifierait considérablement la programmation que l'apprenant connaisse les bases des tableaux (taille fixe, et on ne parle pas des pointeurs).

C'est effectivement l'impression que j'ai eu en relisant ou écrivant certains passages, le plus récemment dans le chapitre sur les fichiers avec tous les petits détails spécifiés par la norme… Maintenant, je pense vraiment que cela est nécessaire.

Fût-ce t'ils un peu lourds, si certains détails sont omis, je crois que ce sera le casse-pipe assuré pour une partie des lecteurs

Le soucis, c'est qu'un tel programme n'est alors pas utilisable dans l'environnement d'exécution. Si je prends l'exemple du shell POSIX, le programme serait considéré comme avoir échoué alors qu'en fait il retourne le nombre de fichiers correctement décompressés.

Cela me paraît une excellente idée, merci.
Nous pourrions même peut-être introduire l'en-tête <time.h> pour aider le lecteur.

Le puissance 4, je préfères le garder pour le TP de la deuxième partie où je comptais notamment permettre aux joueurs de choisir la taille de la grille (pour mettre en pratique l'allocation dynamique) et de sauvegarder et restaurer une partie (manipulation des fichiers). Je n'avais pas encore songer à la création d'une IA, mais c'est également une très bonne idée (encore merci).

Quant au morpion, cela me paraît aussi peu « sexy » qu'une calculatrice à notation polonaise inverse (bon, ok, le morpion est quand même plus drôle). Aussi, je crains qu'il ne soit pas possible de le réaliser sans avoir vu les tableaux (ou alors il y aurait une variable pour stocker l'état de chaque case).

Sur ce point, je pense que nous sommes (et seront) catégoriques : les tableaux ne doivent pas être vus avant les pointeurs. Ceci tient à la nécessité d'expliquer un peu le fonctionnement de la mémoire vive (dû à l'opérateur d'indexation) et à leur facétieuse règle de conversion implicite.

Le puissance 4, je préfères le garder pour le TP de la deuxième partie où je comptais notamment permettre aux joueurs de choisir la taille de la grille (pour mettre en pratique l'allocation dynamique) et de sauvegarder et restaurer une partie (manipulation des fichiers). Je n'avais pas encore songer à la création d'une IA, mais c'est également une très bonne idée (encore merci).

Quant au morpion, cela me paraît aussi peu « sexy » qu'une calculatrice à notation polonaise inverse (bon, ok, le morpion est quand même plus drôle). Aussi, je crains qu'il ne soit pas possible de le réaliser sans avoir vu les tableaux (ou alors il y aurait une variable pour stocker l'état de chaque case).

Il suffit de 9 variables, ce qui reste gérable sans tableau, contrairement au Puissance 4 où ça ne serait vraiment pas sexy¹. Quant au côté « sexy », ce n'est pas tant le morpion en lui-même qui serait intéressant que l'IA pour jouer contre. Et sinon, oui, je pense que le Puissance 4 peut rester réservé pour un TP du chapitre 2 de niveau facile. (De manière générale, je suis pour les sujets de TP qui permettent vraiment d'avoir une version facile, une version difficile et éventuellement d'autres entre les deux.)

Bonjour à tous !

La beta du tutoriel a été mise à jour.

Merci pour vos relectures

• déplacement du chapitre sur le préprocesseur dans la partie 3 ;
• ajout d'un TP après le chapitre sur les sélections demandant de réaliser un programme déterminant le jour de la semaine correspondant à une date donnée ;
• déplacement du chapitre sur la gestion d'erreur après le chapitre sur le TP dans la première partie (la fonction pow() étant présentée dans ce dernier) ;
• déplacement du TP de la calculatrice après le chapitre sur les fonctions.

Finalement, nous avons préféré conserver le TP de la calculatrice afin de pouvoir présenter la fonction pow() et ainsi pouvoir parler de la variable errno dans le chapitre sur la gestion d'erreur.

Bonjour, au sujet de l'installation des outils sous Mac OS X (il vaut mieux écrire Mac OS X ou OS X, car Mac OS concerne un système d'exploitation non basé sous Unix, datant d'avant 2001), vous suggérez l'usage de la ligne de commande plutôt que de Xcode. Je trouve ce choix peu user-friendly, mais j'y reviendrais.

Il conviendrait d'abord de fournir des instructions à jour (mais si vous n'avez pas de système sous OS X, je comprends que vous n'avez pas pu tester).

Vous proposez de créer un alias zcc basé sur gcc. Manque de pot, depuis quelques années, Apple est passé au compilateur clang (http://clang.llvm.org). Durant quelques temps, les deux compilateurs étaient livrés, mais par exemple sur mon installation de Yosemite (OS X 10.10), je n'ai pas gcc. Il est possible de l'installer par Macports toutefois.

Je persiste à penser (même s'il peut aussi être utile de savoir se débrouiller à compiler en ligne de commande), que pour une première approche, l'usage d'Xcode sera plus agréable pour un utilisateur sous OS X. Mais je conçois que la rédaction de certains chapitres soit plus lourde dans ce cas (par exemple, dans le chapitre « Découper son projet », il faudra préciser comment procéder sous Xcode).

En gros, sous Xcode : création d'un projet de type « Command Line Tool », langage C (par défaut c'est GNU99 qui est choisi, mais les version 89 et 11 sont aussi disponibles), et c'est bon, un fichier main.c est créé, contenant :

1
2
3
4
5
6
7

#include <stdio.h>

int main(int argc, const char * argv[]) {
    // insert code here...
    printf("Hello, World!\n");
    return 0;
}

Il suffira de modifier à sa guise. La compilation et l'execution se font par simple clic sur un bouton (la première fois, il est proposé d'activer un mode de déboggage en entrant le mot de passe administrateur).

En cas d'erreurs, celles-ci sont affichées de façon plus graphiques, un surlignant les lignes fautives, accompagnées de l'erreur, par exemple :

warning: implicit declaration of function 'printfa' is invalid in C99

si j'utilise printfa plutôt que printf.

Quant à employer les fichiers main.c et autre.c (comme proposé dans le chapitre), il suffira de créer un fichier autre.c à côté de main.c, et de cliquer à nouveau sur le bouton de compilation et d'exécution.

Il y aurait d'autres points à aborder, par exemple lorsque vous proposez d'employer zcc -lm main.c pour l'usage de la bibliothèque mathématique, plutôt que l'habituel #include <math.h> dans le fichier (ceci étant, il est possible également de personnaliser les options du compilateur clang employé par Xcode).

Si vous avez besoin d'informations complémentaires, n'hésitez pas à me demander, je vérifierais dans ce cas chaque point qu'il y aurait à adapter pour l'usage sous Xcode.

Remarque additionnelle : la dernière phrase du chapitre « Découper son projet » comporte un mot mal orthographié :

Dans le chapitre suivant, nous aboderons

aboRderons.

Salut,

Tout d'abord, merci pour ces retours.

Merci pour cette précision, je corrige de suite.

Hmm… Il semble en effet que GCC ne soit plus inclus à partir de Xcode 5. Dans ce cas, je vais ajouter un paragraphe demandant de vérifier la présence de l'un ou l'autre.

À mes yeux, la présentation d'un IDE à un débutant est une erreur. Ces outils sont réalisés par et pour des programmeurs expérimentés qui connaissent déjà les rouages de la compilation et la gestion de projet. Le plus souvent, le débutant se noye dans l'interface graphique et ne perçoit pas ce qu'il fait. À l'inverse, le passage par la ligne de commande rend tout cela beaucoup plus transparent.

Sous GNU/Linux et *BSD, la bibliothèque mathématique est une bibliothèque à part de la bibliothèque standard, c'est pour cela qu'il est nécessaire de spécifier l'option -lm lors de la compilation. L'en-tête <math.h> (présent dans les exemples de codes) ne sert qu'à fournir les déclarations de fonctions, il est donc insuffisant pour réaliser la compilation.

Merci, c'est corrigé.
Notes toutefois que les modifications ne seront visibles que lors de la prochaine mise à jour de la beta.

Hmm… Il semble en effet que GCC ne soit plus inclus à partir de Xcode 5. Dans ce cas, je vais ajouter un paragraphe demandant de vérifier la présence de l'un ou l'autre.

Alors GCC n'est pas inclus, mais /usr/bin/gcc est un alias pour /usr/bin/clang (et /usr/bin/g++ est un alias pour /usr/bin/clang++). Étant donné que les deux compilateurs ont presque le même comportement, je ne suis pas sur que ça vaille le coup d'aborder la différence plus que ça dans un cours pour débutants.

Sous GNU/Linux et *BSD, la bibliothèque mathématique est une bibliothèque à part de la bibliothèque standard, c'est pour cela qu'il est nécessaire de spécifier l'option -lm lors de la compilation. L'en-tête <math.h> (présent dans les exemples de codes) ne sert qu'à fournir les déclarations de fonctions, il est donc insuffisant pour réaliser la compilation.

Sous OS X, tout un tas de bibliothèques sont liées par défaut lors de l'appel à ld. Entre autres, la libm. Donc -lm n'est pas à strictement parler nécessaire sous OS X, mais ça ne fait pas de mal d'en parler par contre, pour ne pas se faire avoir en changeant d'OS.

Aah ! Voilà qui est intéressant, merci. Du coup, je vais effectivement laissé le passage tel quel histoire d'éviter une complication inutile.

Ok, merci pour cette précision.

J'ignorais, j'avais fait un man gcc qui donnait no manual entry, mais which gcc donne effectivement /usr/bin/gcc.

Concernant l'usage d'un IDE, une des raisons qui fasse que son utilisation est plus agréable est que l'édition et la compilation se font dans la même fenêtre. Ainsi, en cas d'erreur, on n'a pas à jongler entre le terminal et l'éditeur de texte (évidemment, ce problème ne concerne pas les purs barbus qui codent tout dans le terminal). Par ailleurs, l'autocomplétion est disponible dans Xcode (gratuit), mais pas dans TextWrangler (gratuit). Smultron est payant (certes 5 euros, c'est pas grand chose, mais il y aura toujours des utilisateurs à qui cela posera problème, par exemple des mineurs qui liront le tuto).

Par exemple, sous Xcode, l'utilisateur, s'il a déjà défini la variable nombre, se verra proposer sa réutilisation aux moments opportuns, lorsqu'il tape les premières lettres :

Par exemple, sous Xcode, l'utilisateur, s'il a déjà défini la variable nombre, se verra proposer sa réutilisation aux moments opportuns, lorsqu'il tape les premières lettres :

Pas besoin de sortir un IDE pour ça. Un bon éditeur de texte (Atom par défaut, SublimeText avec un plugin, TextMate avec un plugin) le fait aussi. Pour le jonglage entre fenêtres je suis d'accord, mais vu que j'utilise des commandes (git, cmake, make) non fournies avec XCode, il vaut mieux que je change de fenêtres.

Si le but du tutoriel est d'apprendre le langage C (ce qui est déjà un gros morceau), je trouve que brouiller l'apprentissage en y ajoutant une navigation entre deux logiciels, avec des commandes à entrer au Terminal, n'est pas l'idéal. Je vais passer le tuto en revue, mais, a priori, indiquer en début de tuto comment créer un fichier .c dans Xcode, ajouter des fichiers au projet, et appuyer sur le bouton de compilation devrait être suffisant. Il est toujours possible d'indiquer aux utilisateurs avancés (ou curieux) qu'il est aussi possible de faire les manipulations en mode Terminal en suivant les indications pour GNU/Linux, BSD et autres Unixoïdes*.

C'est bien entendu vous qui voyez, mais je pense que ce serait un plus qui ne coûte pas très cher.

Apres je ne suis pas surs que ce soit à un tuto sur le C de faire ça. Sinon il faudrait aussi expliquer a minima sur un IDE par OS comment faire. Le sujet du tuto est déjà assez conséquent pour limiter ça.

Sur les Unixoïdes, y a-t-il un IDE qui s'impose ? Sinon, je suppose que leurs utilisateurs ne seront pas dépaysés par la ligne de commande et le terminal.

Sur Windows qu'y a-t-il ? (j'ignore totalement)

Sur OS X, Xcode me semble s'imposer. Il suffira d'indiquer de créer un nouveau projet (menu File > New > Project…), de type OS X > Application > Command Line Tool, de choisir le langage C, de lui donner un nom, ce qui crée à l'emplacement choisi un dossier nommé selon le nom du projet. Il contient un sous-dossier de même nom, lequel contient un prototype de fichier main.c. L'ajout de fichiers au projet est très simple également.

Il me semble que les tutoriels d'initiation à LaTeX passent aussi par une phase IDE plutôt que strictement terminal.

L'objectif est justement de laisser l'utilisateur jongler entre les différents programmes pour que ce dernier cerne bien le rôle de chacun d'eux. Alors, oui, cela est moins confortable qu'un IDE, mais à mon sens c'est la solution la plus profitable pour un débutant. L'essentiel n'est pas qu'il ait diverses fonctionnalités (pratiques ou non) à disposition, mais qu'il comprenne ce qu'il fait. Or, à mes yeux, cela n'est possible que via la ligne de commande.

Il ne me paraît pas y avoir de différence de diffcultés entre configurer et utiliser un IDE et configurer et utiliser un éditeur de texte et un terminal.

C'est la solution qui avait été adoptée auparavant, mais elle a été abandonnée par après pour les raisons que j'ai évoquées précédemment et aussi parce que cela est assez pénible de détailler x interfaces avec les captures d'écran qui vont bien et qui change toutes les x versions.

Je ne sais pas s'il y a un IDE majoritaire, mais je connais Code::Blocks, Qt Creator et Geany.

Code::Blocks et Visual Studio.