;-)) :
C'est un langage structuré, généralement compilé, de haut niveau.
Pour le « haut niveau », cela dépend un peu du point de vue en fait. À la fin des années 70, les réfractaires disaient de lui que c'était « encore un assembleur ». D'autres le trouvent donc de bas niveau ... On vous renvoie à l'introduction et aux avant-propos de K&R (cf. 3.9).
Il dispose d'une bibliothèque standard (normes ANSI, ISO, IEEE, AFNOR,...) permettant un minimum d'interactions avec la machine. Il a été normalisé (cf. 3.7) ce qui permet de recompiler un source (n'utilisant que la bibliothèque standard) sur n'importe quelle machine disposant d'un compilateur respectueux de la norme.
Cett dernière ne porte que sur le langage proprement dit et sur le contenu de la bibliothèque standard. Cette dernière ne contient que le strict minimum pour interagir avec la machine. Ainsi, peut-on manipuler du texte et des fichiers, déterminer le temps de calcul ou gérer la mémoire mais guère plus. Le reste est à la charge du programmeur, ou des bibliothèques spécifiques du système.
Au vu de ce qui précède, on peut donc donner cette autre définition :
Le C est un langage de programmation dont la structure est proche de la machine de Von Neumann.
Donc ce qui importe, ce n'est pas tant qu'on puisse recompiler notre programme type sans modification sur toutes les plateformes, c'est la « sémantique ». Le fait d'écrire en C standard n'implique nullement que le programme soit portable en ce sens qu'il a la même sémantique sur tous les compilateurs. Il est important de noter que la définition de C définit une machine abstraite « paramétrée » -- les paramètres variant d'un compilateur à un autre.
Rappelons ici encore que le langage ne gère ni la souris, ni l'écran, ni votre store électrique (pardon, nucléaire) dernier cri. Tout cela est du ressort de votre OS.
Voir aussi 3.5.
Merci à Emmanuel Delahaye, Gabriel Dos Reis, Vincent Lefèvre, Thomas Pornin et tous les autres pour la rédaction de cet article.
Voir aussi 3.7.
Tout compilateur C est fourni avec une bibliothèque de fonctions, en principe standard.
Voir aussi 3.5.
char fait 8 bits est
l'exemple le plus flagrant (cf. 16.2).
Un autre exemple classique est de croire que toutes les machines
supportent l'ASCII ...
Pour faire ce système, il en est venu à penser Unix de sorte que les deux seuls éléments qui dépendent du hardware se résument au strict minimum à savoir le compilateur et le noyau. Il lui fallait un langage d'assez bas niveau et simple. Se basant sur le BCPL, Thompson a donc mis au point le langage B (pour Unics, 1969-1972) puis Ritchie l'a amélioré pour en faire le langage C (Unix, 1973).
Voir aussi 3.3 et surtout le papier de Dennis Ritchie : cm.bell-labs.com/cm/cs/who/dmr/chist.html pour plus de détails.
La popularité du C tient alors autant à sa simplicité qu'à la pénétration d'Unix (et donc l'apparition de compilateurs C sur les machines ie. la nouvelle portabilité des programmes). Des compilateurs sont alors assez vite apparus sur d'autres plateformes qu'Unix, contribuant ainsi à la diffusion (un peu anarchique) du langage.
En 1978, Brian W. Kernighan et Denis M. Ritchie ont publié The C Programming Language (ISBN:0131101633) (On trouve tous les numéros ISBN des différentes éditions sur cm.bell-labs.com/cm/cs/cbook/index.html ). Dès lors, les compilateurs ont commencé à suivre les recommandations et indications des auteurs. Cet ouvrage a fait office de norme pendant longtemps, le langage qui y est décrit s'appelle le C K&R, en référence aux 2 auteurs.
Entre-temps, en 1988, durant la période de travail du comité, la deuxième édition du K&R a été publiée (ISBN: 0131103709). Elle a été complètement réécrite et on y a ajouté des exemples et des exercices afin de clarifier l'implémentation de certaines constructions complexes du langage.
Dans sa plus grande partie, le standard C ANSI de 1989 officialise les pratiques existantes, en ajoutant quelques nouveautés provenant du C++ comme les prototypes de fonctions et le support de jeux de caractères internationaux (notamment les très controversées séquences trigraphes). Le standard C ANSI décrit aussi les routines pour le support des bibliothèques d'exécution du C.
L'International organization for standardization (www.iso.ch ) a adopté en 1990 ce standard en tant que standard international sous le nom de ISO/IEC 9899:1990 (ou C90). Ce standard ISO remplace le précédent standard ANSI (C89) même à l'intérieur des USA, car rappelons-le, ANSI est une organisation nationale, et non internationale comme l'ISO. Aux USA, on parle alors de ANSI/ISO 9899-1990 [1992], en France de ISO/CEI 9899:1990.
Les standards ISO, en tant que tel, sont sujets à des révisions,
par la diffusion de « Technical Corrigenda »
2 et de « Normative
Addenda »3. C'est ainsi qu'en
1995, le Normative Addendum 1 (NA1)
(www.lysator.liu.se/c/na1.html
) parfois appelé
Amendment 1 (AM1) fut approuvé en 1995. Il ajouta
environ 50 pages de spécifications diverses concernant notamment
de nouvelles fonctions dans la bibliothèque standard pour
l'internationalisation, et les séquences digraphes pour le jeu de
caractères ISO 646, autorisant ainsi les terminaux ne possédant
pas certains caractères à utiliser une écriture alternative
(<% %> pour { et } ou
encore <: :> pour [ et
]).
Peu de temps après, toujours en 1995, le Technical Corrigendum 1 (TCOR1) (anubis.dkuug.dk/JTC1/SC22/WG14/www/docs/tc1.htm ) fut approuvé et modifia le standard ISO en environ 40 points, la plupart d'entre eux étant des corrections mineures ou des clarifications. En 1996, on publia aussi le TCOR2 (anubis.dkuug.dk/JTC1/SC22/WG14/www/docs/tc2.htm ) qui apporta des changements encore plus mineurs que le TCOR1. TCOR2 reformulait certains points abscons.
À partir de 1997, on désigne par C95 l'ensemble des documents TCOR1, TCOR2 et AMD1 et de la norme C90. Le terme C95 est utilisé dans le « rationale » de C99.
En fait ce n'est pas directement l'ISO qui travaille sur les standards, elle ne fait que les approuver conjointement avec l'IEC (www.iec.ch ). C'est pour cette raison que les standards ISO du C commencent par ISO/IEC... De plus, l'ISO charge des comités techniques de travailler dans tels et tels domaines. En l'occurrence, le JTC1 (www.jtc1.org ) est le comité spécialisé dans le domaine informatique. Le JTC1 à son tour répartit le travail dans plusieurs sous-comités : celui qui nous intéresse est le SC22, dont le but est la standardisation des technologies de l'information. Or le SC22 lui-même est subdivisé en Working Groups, le WG14 étant celui qui est en relation avec le C.
Finalement, c'est le ISO/IEC JTC1/SC22/WG14 qui rédige la norme ISO du C, le SC2 approuve alors le projet final (FDIS), puis le transmet au JTC1 qui approuve la nouvelle norme ISO.
En réalité, le groupe de travail WG14 est composé d'organismes nationaux --- tels ANSI (le plus actif), AFNOR, BSI, CSA, DS, ... --- représentants les pays prenant part à la normalisation (je vous passe les détails de pays votants, observateurs, et autres). Chacun de ces organismes travaille sur le langage. L'ANSI dispose elle aussi d'un comité spécialisé dans le domaine informatique : le X3 (www.x3.org ), qui depuis 1996 s'appelle NCITS (prononcez insights en anglais) (www.ncits.org ) pour National comittee for Information Technology Standards. Lui aussi dispose de comités techniques qui travaillent chacun dans un domaine particulier : le J11 (www.ncits.org/tc_home/j11.htm ) a en charge le langage C. C'est donc le X3J11 qui développe la norme C ANSI aux USA, et qui travaille avec le WG14.
Il se trouve qu'en 1993, lors des réunions bi-annuelles entre le WG14 (ISO) et le X3J11 (ANSI), tout le monde s'est accordé pour dire,
L'idée a alors émergée de créer un nouveau standard du C qui regrouperait le C90, le NA1, le TCOR1 et le TCOR2, apporterait d'autres modifications afin de maintenir le C en phase avec les techniques de programmation d'aujourd'hui, et qui minimiserait les incompatibilités avec le C++, sans pour autant vouloir transformer le C en C++. Ce projet de nouveau standard du C a pris le nom de code C9X avec l'intention qu'il serait publié dans la fin des années 1990 (anubis.dkuug.dk/JTC1/SC22/WG14/www/charter.html ).
Vers la fin de la normalisation de C99, SC22/WG21 -- le groupe de travail qui s'occupe de C++ -- a adressé une requête formelle (par l'intermédiaire du bureau SC22) à SC22/WG14 pour documenter les éventuelles incompatibilités introduites par C99 par rapport à C++ (SC22/WG21 l'avait fait par rapport à C90). SC22/WG14 a répondu qu'il n'avait ni le temps nécessaire ni la compétence pour faire cela.
Cependant, un tel travail (inspiré partiellement de ce que C++ a déjà fait) a été entrepris à titre personel par David Tribble dont la contribution se trouve ici : www.david.tribble.com/text/cdiffs.htm .
Tout au long du projet C9X, des « drafts » (brouillons) du projet sont distribués afin que tout le monde puisse donner son avis et, le cas échéant, revoir certaines parties. Le dernier draft disponible est le document n869 (www.dkuug.dk/jtc1/sc22/wg14/www/docs/n869/ ) datant de janvier 1999. Ce document est celui le plus proche de la norme et que l'on peut obtenir gratuitement: il définit C9X, le projet de la norme.
À l'heure actuelle, C99, qui est équivalent à C2k, n'est pas encore totalement supportée par les compilateurs. Il faut un certain temps pour implémenter toutes les nouvelles fonctionnalités de C99. Tout ce dont on peut être sûr, c'est que n'importe quel bon compilateur supporte au moins la norme C90.
Voici d'ailleurs au passage quelques unes des nouveautés de C99:
complex.h,
long long int et unsigned long long
int d'au moins 64 bits,
vscanf(),
//,
snprintf(),
Théoriquement, ISO révise les normes tous les cinq (5) ans. Les groupes de travail n'ont pas besoin d'attendre les cinq ans avant de commencer à travailler sur les éventuelles extensions. Cependant le travail de normalisation prend un certain temps --- pensez par exemple que ANSI a débuté le travail de normalisation de C89 en 1983 et n'a fini qu'en 1989. Il est possible qu'un C04 soit publié en 2004, ce serait C99 augmenté de quelques amendements. Le travail de normalisation est long et pénible par moment.
Un grand merci à « After » pour le brouillon de cet article et à Gabriel Dos Reis, Éric Lévénez et Antoine Leca pour leurs relectures avisées.
Pour apprendre le C, il vous faudra un bon compilateur,
de la doc' papier, un bon dictionnaire d'anglais et un stock
d'aspirine ;-)
On trouvera les exercices corrigés du précédent dans : Tondo C.L. & Gimpel S.E. (2000), Exercices corrigés sur le langage C, Dunod, Paris.
En complément, Braquelaire J.-P. (2000), Méthodologie de la programmation en C, Bibliothèque standard, API POSIX, 3ème édition, Dunod, Paris. sera une excellente ressource.
Enfin, citons l'excellent Kernighan B.W. & Pike R., (1999) The Pratice of Programming, Addison-Wesley, Reading. (cm.bell-labs.com/cm/cs/tpop/index.html ).
Il arrive souvent au programmeur de devoir résoudre des problèmes d'Algorithmique. Il peut se reporter à la bible en la matière : Knuth D.E. (1997), The Art of Computer Programming, third edition, Addison-Wesley, Reading. (communément abrégé en TAoCP). Il y a aussi : Sedgewick R. (1991), Algorithmes en langage C, InterÉditions, Paris. ou cet autre : Loudon K. (2000), Maîtriser les Algorithmes en C, O'Reilly, Paris.
Une bonne introduction à l'Analyse Numérique en C est : Press W.H., Flannery B.P., Teukolsky S.A., Vetterling W.T. (1992), Numerical Recipes in C, The Art of Scientific Computing, second edition, Cambridge University Press. (communément abrégé en NR, PFTW ou Numerical Recipes selon). C'est disponible en ligne (voir 4.5).
Il existe aussi : Engeln-Müllges G. & Uhlig F. (1996), Numerical Algorithms with C, Springer, Berlin. (fourni avec les sources et djgpp, pour plateformes Wintel, sur CD).
On trouve des cours de C sur le web en français sur les sites universitaires. Ainsi, on peut citer : ftp.ltam.lu/TUTORIEL/COURS-C/COURS-C.ZIP , www.enseignement.polytechnique.fr/profs/informatique/Eric.Goubault/poly/cours.ps.gz , www.loria.fr/~mermet/CoursC/coursC.ps , www.enseignement.polytechnique.fr/profs/informatique/Jean-Jacques.Levy/poly/polyx-cori-levy.ps.gz , www-inf.int-evry.fr/COURS/COURSC/
On lira aussi très attentivement : ftp.laas.fr/pub/ii/matthieu/c-superflu/c-superflu.pdf qui contient tout ce qu'il faut savoir pour commencer à programmer proprement en C. Il contient aussi une grosse bibliographie.
Un CD complet en ligne sur le C : www.infop6.jussieu.fr/cederoms/Videoc2000/
Les sources du bouquin de Braquelaire (dernière édition : la 3ème, 2ème tirage...) : dept-info.labri.u-bordeaux.fr/~achille/MPC-3/2T/MPC-3-2t.tar.gz
Les sources du bouquin de Loudon : www.editions-oreilly.fr/archives/algoc.zip .
La bibliothèque standard : www.dinkumware.com/htm_cl/index.html#Table-of-Contents
Le IOCCC est un concours de hackers qui récompense chaque année le pire programme C : www.ioccc.org/index.html
Un freezzine en anglais : www.gmonline.demon.co.uk/cscene/
Sur les sites universitaires on trouve toujours des cours en ligne, du code, etc ...
Signalons aussi (même si c'est hors-sujet) le fichier ftp.laas.fr/pub/ii/matthieu/tpp/tpp.ps.gz qui explique comment utiliser make et ftp.laas.fr/pub/ii/matthieu/cvs.ps.gz comment utiliser CVS.
(Merci à Antoine Leca).
man-fr-x.x où x.x est le numéro
de version (actuellement 0.8, bientôt 0.9).
(informations bienvenues à pascal.cabaud@wanadoo.fr )
faq-fclc 5/3/2002 (8h 59:04)