Donner une définition du C est assez difficile, je vous propose
celle-ci (avec laquelle je me suis le moins fait insulté
;-)) :
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.
Cette 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.
À créer ses propres logiciels, selon ses besoins, de manière portable ie. indépendemment de la machine et du système d'exploitation.
Il a été créé par Brian Kernighan et Dennis Ritchie, sur les cendres du BCPL (Basic Combined Programming Language de Martin Richard, le BCPL étant une simplification du CPL, Cambridge Programming Language) et du B (langage expérimental de Ken Thompson), dans les années 70 lorsqu'ils écrivaient Unix.
Voir aussi 3.7.
On peut tout faire ou presque. On peut créer son propre système d'exploitation (les Unix-like sont encore écrits en C pour la majorité), son interface graphique, sa base de données, son driver (pilote) pour la dernière machine à café USB, etc.
Tout compilateur C est fourni avec une bibliothèque de fonctions, en principe standard.
Voir aussi 3.5.
Si la norme du C permet une bonne portabilité, il faut noter que
l'on peut faire des choses parfaitement dépendantes de la
cible. Ainsi, les Unix sont-ils écrits en C. Mais
point n'est besoin d'utiliser des API (Application Programming Interface i.e.
interface de programmation d'applications littéralement ; autrement-dit bibliothèque)
exotiques pour perdre en
portabilité, présupposer qu'un 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 ...
Le C++ est un langage à objets basé sur le C. Il y a des différences suffisantes pour qu'il s'agisse d'un autre langage, ayant son forum propre : fr.comp.lang.c++.
Il existe un autre langage à objets basé sur le C. Il s'agit d'Objective-C. Il est principalement utilisé dans Mac OS X et dans GNUStep.
Le langage C est le fruit des efforts conjoints de Brian Kernighan, Denis Ritchie et Ken Thompson. Le dernier dirigeait le projet de réécriture de Multics (un OS multi-utilisateurs, projet abandonné) et il voulait créer un OS qui soit portable répondant à ses attentes, permettant un accès simple aux périphériques. De fil en aiguille, c'est devenu un système largement indépendant du hardware. À l'époque les plateformes étaient toutes si différentes qu'il était commun de donner ses sources et la moindre recompilation d'une machine à une autre demandait souvent un effort de portage.
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/). 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.
Devant la popularité du C, l'American National Standard Institut (www.ansi.org) charge en 1983 le comité X3J11 de standardiser le langage C. On parle à ce moment-là de C pré-ANSI. Après un processus long et complexe, le travail du comité a finalement été approuvé : le 14 décembre 1989, le standard ANSI X3.159-1989 (ou C89) est né. Il est publié au printemps 1990.
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.
Durant les années 1990, lorsqu'on parle de C89 (C ANSI) ou de C90 (C ISO), ce sont deux appellations différentes pour en fait une seule et même norme. Il existe aussi une norme européenne et une française (AFNOR) dont on entend beaucoup moins parler, qui sont aussi semblables à la norme ISO. Noter que la norme française (AFNOR) est parfaitement identique à l'ISO, l'AFNOR se contentant de publier l'ISO (en anglais) en guise de norme française (le site du groupe de normalisation du C à l'AFNOR : forum.afnor.fr/afnor/WORK/AFNOR/GPN2/Z65B/, ne pas se fier aux apparences, il s'agit du groupe sur le C, la page est un peu vieille et le groupe --- réduit passé un temps à Antoine Leca --- a été recueilli par le groupe chargé du C++).
Les standards ISO, en tant que tel, sont sujets à des révisions,
par la diffusion de « Technical Corrigenda »
(« Rectificatif technique ») et de « Normative
Addenda » (« Amendement »). 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 (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.
Le 1er décembre 1999, la norme officielle a été adoptée par l'ISO sous le nom de ISO/IEC 9899:1999, ou plus simplement C99. Elle a aussi été publiée par l'ANSI, qui travaille conjointement avec l'ISO, sous le nom de ANSI/ISO/IEC 9899-1999, mais que l'on appelle C2k.
À l'heure actuelle C99 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,//,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.
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.
Une nouvelle version de la norme C a été publiée le 8 décembre 2011 sous les références ISO/IEC 9899:2011. Son nom de code était C1X et est maintenant C11.
Voici quelques évolutions de C11 par rapport à C99
uchar.h,_Generic permettant d'écrire des macros utilisant des types génériques,_Noreturn indiquant qu'une fonction ne se termine jamais, comme exit(),_Static_assert,threads.h,_Thread_local et _Atomic pour la gestion des threads,stdalign.h,aligned_alloc, at_quick_exit et quick_exit,Le compilateur GCC a un support limité pour certaines évolutions de la norme C11, et peut être activé par -std=c11
ou par -std=iso9899:2011.
D'un éditeur de texte basique, d'un compilateur (voir 4.2), d'un bon bouquin (voir 3.9), d'un débogueur et de beaucoup de patience. En principe, compilateur, bibliothèque(s), (débogueurs) et doc' sont fournis ensembles.
Pour apprendre le C, il vous faudra un bon compilateur,
de la doc' papier, un bon dictionnaire d'anglais et un stock
d'aspirine ;-)
Le livre que tout programmeur C se doit de connaître et d'avoir sur son bureau est Kernighan B.W. & Ritchie D.M. (1997), Le langage C Norme ANSI, 2ème édition, Dunod, Paris.
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/).
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).
Là par exemple : cm.bell-labs.com/cm/cs/who/dmr/, c'est la page de Denis Ritchie. Il y a aussi celle de Brian Kernighan : cm.bell-labs.com/cm/cs/who/bwk/.
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/#Table-of-Contents
Le IOCCC est un concours de hackers qui récompense chaque année le pire programme C : www.ioccc.org/
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. Je recommande aussi vivement l'utilisation d'outils tels que CVS : www.cvshome.org/docs/ www.idealx.org/fr/doc/cvs/cvs.html matrix.samizdat.net/serveurs/cvs/tut_cvs.html
Là : wwwold.dkuug.dk/jtc1/sc22/open/n2794/n2794.txt On peut aussi l'acheter soit auprès de l'AFNOR (très cher) soit en ligne aux USA (environ 20 $ US), ça se passe ici : www.cssinfo.com/ncitsgate.html ou encore là webstore.ansi.org/ansidocstore/product.asp?sku=ANSI%2FISO%2FIEC+9899%2D1999
(Merci à Antoine Leca).
Le brouillon finale de la norme C11, passée en avril 2011 est disponible sous la référence http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf. La norme http://www.iso.org/iso/fr/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=57853 est achetable, pour CHF 338, à l'ISO.
Là : www.eskimo.com/~scs/C-faq/top.html
On peut trouver les pages de manuels en Français pour la plupart des Unix, sous la forme de packages du système. Pour Linux, vous les trouverez ici : perso.club-internet.fr/ccb/ ou encore là : www.delafond.org/traducmanfr/
Tout ce qui concerne le C à propos des CGI est là : www.chez.com/nospam/cgi.html Il y a aussi une FAQ ici : www.htmlhelp.com/faq/cgifaq.html
(informations bienvenues à pascal.cabaud@wanadoo.fr)
Oui, on peut programmer Orienté Objet en C. Voici un document qui présente ces techniques : ldeniau.home.cern.ch/ldeniau/html/oopc/oopc.html