1.1 Copyright de la FAQ de comp.lang.c
" The comp.lang.c FAQ list is Copyright 1990-1999 by Steve Summit. Content from the book C Programming FAQs: Frequently Asked Questions is made available here by permission of the author and the publisher as a service to the community. It is intended to complement the use of the published text and is protected by international copyright laws. The content is made available here and may be accessed freely for personal use but may not be republished without permission. "
1.2 Qu'en est-il de ce document ?
* Steve Summit a rédigé
la version anglo-saxonne sur laquelle nous nous sommes basés. On
en a traduit de longs passages, réorganisé, annoté,
repensé une partie et réécrit complétement
d'autres paragraphes, ce avec son consentemment.
* Les auteurs comme
les contributeurs de cette FAQ ne garantissent rien, ni que les conseils
donnés ici fonctionnent, ni que le code compile et fonctionne correctement,
ni que votre machine ne va pas s'autodétruire instantanément
après lecture de ce message. Autrement dit, vous êtes entièrement
responsable de ce que vous faites des informations données ici.
En cas de pépin, vous ne pouvez vous en prendre qu'à vous
même. En outre, seule la version courante de ce document fait foi.
* Les copies conformes
et versions intégrales de ce document sont autorisées sur
tout support pour peu que cette notice soit préservée.
Une utilisation commerciale devra faire l'objet d'une autorisation préalable,
notamment de Steve Summit.
C'est une Foire Aux Questions (les anglos-saxons disent Frequent Asked Questions ou questions fréquemment posées). Elle regroupe les réponses aux questions récurrentes sur news:fr.comp.lang.c.
Elle est rédigée à l'initiative de Guillaume Rumeau (guillaume.rumeau@wanadoo.fr).
Les rédacteurs
de la FAQ sont :
* Guillaume Rumeau (guillaume.rumeau@wanadoo.fr),
* Thomas Pornin (Thomas.Pornin@ens.fr),
* Pascal Cabaud (pascal.cabaud@wanadoo.fr),
mais elle ne saurait
exister sans les contributions de :
" -hs- ", " After ",
" ironfil ", " MacLord ", Edgar Bonnet, Erwan David,
Thomas Deniau, Gabriel
Dos Reis, Laurent Dupuis, Horst Kraemer, Antoine
Leca, Vincent Lefèvre,
Fabien Le Lez, Éric Lévénez, Serge Paccalin, Yves
Roman, Michel Simian,
et tous les autres...
et n'oublions pas bien
sûr Steve Summit.
À la page de Guillaume
Rumeau :
http://www.isty-info.uvsq.fr/~rumeau/fclc/
et deux fois par mois sur
news:fr.comp.lang.c
et news:fr.usenet.reponses.
Ce document étant
rédigé par des humains, il peut contenir des erreurs. Vous
êtes vivement invités à les signaler soit en postant
sur news:fr.comp.lang.c soit en écrivant à l'un des (aux)
rédacteurs.
(voir aussi 2.3)
Il faut commencer par
les reformuler le plus précisément possible (par exemple
les reformuler en questions moins ouvertes) ; décrire les problèmes
aide beacoup.
Quand on commence à
avoir une idée, chercher les mots clefs décrivant le problème
à l'aide de moteurs de recherche, par exemple http://www.google.com/.
Regardez aussi ce que sait faire
http://www.copernic.com/fr.
Si vous n'avez toujours
pas de reponse, analysez les différents forums disponibles, et posez
la question dans celui qui vous semblera le plus adapté ; si il
y a plusieurs questions qui semblent pouvoir aller dans plusieurs forums,
rédigez plusieurs messages (il y aura plus de réponses,
car les réponses
seront moins longues à écrire...).
Si la question est très
technique et n'obtient pas de réponse valable, faites l'effort de
la re-rédiger en anglais et/ou demandez gentiment une traduction
si vous n'êtes pas sûr de votre anglais, il y a suffisament
de francophones sur les groupes internationaux pour qu'une bonne âme
vous rende service.
Avant de poster (sur news:fr.comp.lang.c), mieux vaut se demander si :
* la question porte-t-elle
sur le C ISO ? cf. 3.7.
* la réponse
est-elle dans la doc' ? dans mon bouquin ? Bonne lecture !
* la réponse
est-elle dans la FAQ ? Bonne lecture !
* la réponse
a-t-elle déjà été donnée ? Pour le savoir,
il faut chercher sur http://www.deja.com/.
Comme il est dit et
redit quotidiennement sur news:fr.comp.lang.c, le forum ne traite ni de
graphisme, ni de Windows.
À ce sujet, rappelons
que la FAQ de news:fr.comp.os.ms-windows.programmation est disponible ici
:
http://www.usenet-fr.news.eu.org/fr.usenet.reponses/comp/os/faq-winprog.html.
(Merci à -hs-
pour l'URL de copernic et à Antoine Leca de m'avoir prêté
sa plume ;-)).
2.7 Dois-je poster sur fr.comp.lang.c ?
Ainsi que le stipule la charte du groupe, les seules questions traitées sur news:fr.comp.lang.c portent sur le C ISO. Pour ce qui a trait avec la programmation Be, DOS, Mac, Unix, Windows, il y a des forums dédiés.
En particulier,
* news:fr.comp.os.ms-windows.programmation
pour la programmation sous Windows,
* news:fr.comp.sys.mac.programmation
pour la programmation sous MacOS, MacOS X.
Pour les autres systèmes,
il n'y a pas de forum spécifique dans la hierarchie news:fr.*.
Pour ce qui concerne
les Unix, news:fr.comp.os.unix et/ou news:fr.comp.os.bsd (ou encore news:news:fr.comp.sys.next)
devraient faire l'affaire.
Dans la hiérarchie internationale, on trouve :
* news:comp.os.msdos.programmer
pour DOS,
* news:comp.unix.programmer
pour Unix,
* news:comp.sys.be.programmer
pour Be,
* news:comp.os.os2.programmer
pour OS/2,
2.8 Comment poster sur fr.comp.lang.c ?
En n'envoyant pas de
pièce jointe, en postant en texte ASCII. Les accents (ISO-8859-1)
sont acceptés. Outre les pièces jointes, le HTML, le quoted
printable et tout ce qui n'est pas text/plain est à proscrire (pas
mal de serveurs de news supprimeront ces contributions indésirables
sans autre forme de procès).
Plus la question est
précise, meilleure sera la réponse. On peut utiliser des
balises dans le sujet, une liste est maintenue par Alexandre Lenoir, disponible
là :
http://www.planete.net/~alenoir/fcsm.html.
Ne donnez pas de noms propres dans les sujets !
Il est de bon ton de
poster les morceaux de code problématiques. Veillez à poster
du code qui compile (sauf s'il ne s'agit que de quelques lignes). Si le
programme est trop gros, donnez une URL où on peut le lire.
Pour répondre,
veillez à ne citer que le strict nécéssaire et à
répondre après le message ou passage cité. Je vous
rappelle qu'il est très impoli pour des raisons évidentes
de demander une réponse par mail et en général vous
n'aurez pas satisfaction. Si vraiment vous y tenez, tentez votre chance
avec le service fourni ici :
http://francette.net/bdr.html
(je n'ai pas testé).
2.9 Comment comprendre le langage utilisé sur fr.comp.lang.c ?
Ceci n'est pas une FAQ sur Usenet mais sur le langage C donc on va faire court :
* OEQLC signifie
" Où Est la Question sur Langage C " autrement dit, votre question
est hors-sujet (off topic),
* OT ou HS
signifie " Hors-Sujet " autrement dit, c'est du bruit,
* RTFM signifie
" Read The F*cking Manual " autrement dit, c'est dans tout bouquin digne
de ce nom (voir 3.9 et 3.10). Pour les âmes sensibles, on traduit
parfois par " Read The Fine Manual ", ou en français par " Regarde
Ton Fichu Manuel ".
3.1 Qu'est ce que le langage C ?
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. 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 plates-formes, 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 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 à "-hs-", Gabriel Dos Reis, Vincent Lefèvre, Thomas
Pornin et tous les autres pour la rédaction de cet article.
3.2 À quoi ça sert ?
À créer ses propres logiciels, selon ses besoins, de manière portable ie.
indépendemment de la machine et du système d'exploitation.
3.3 D'où vient le C ?
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.
3.4 Que peut-on faire en C ?
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.
3.5 Portabilité, matériel, système...
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 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...
3.6 Et le C++ dans tout ça ?
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 :
news:fr.comp.lang.c++.
3.7 ISO, ANSI, K&R, ..., qu'es aquo ?
Les origines
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, il a pensé un système largement
indépendant du hardware. À l'époque les plates-formes é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 et Kernighan l'ont amélioré
pour en faire le langage C (Unix, 1973).
Voir aussi 3.3 et surtout le papier de Dennis Ritchie :
http://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 plates-formes 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)1. 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.
La normalisation
Devant la popularité du C, l'American National Standard Institut
(http://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 finallement été approuvé : le 14 décembre
1989, le standard ANSI X3.159-1989 (ou C89) est né. Il est publié au
printemps 1990.
Entretemps, 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 (http://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.
Détails sur la normalisation
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 :
http://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 "2 et de " Normative Addenda "3. C'est
ainsi qu'en 1995, le Normative Addendum 1 (NA1)
(http://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)
(http://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
(http://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 (http://www.iec.ch).
C'est pour cette raison que les standards ISO du C commence par ISO/IEC...
De plus, l'ISO charge des comités techniques de travailler dans tels et tels
domaines. En l'occurrence, le JTC1 (http://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 est 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 (http://www.x3.org), qui depuis 1996 s'appelle NCITS
(prononcez insights en anglais)
(http://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
(http://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,
1. [(i)] que la révision (prévue dans les textes ISO) de 1995 ne se ferait
pas, et
2. que la révision de 2000 environ aboutirait à une nouvelle version de la
norme (le futur C9X).
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
(http://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 :
http://www.david.tribble.com/text/cdiffs.htm ou là :
http://home.flash.net/~dtribble/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
(http://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.
Dernières nouvelles
Très récemment, 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 (septembre 2000), C99, qui est équivalent à C2k, n'est
pas encore totalement supporté 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:
* tableau à longueur variable,
* support des nombres complexes grâce à complex.h,
* types long long int et unsigned long long int d'au moins 64 bits,
* famille de fonctions vscanf(),
* les fameux commentaires à-la-C++ //,
* les familles de fonctions snprintf(),
* le type booléen,
* etc.
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.
3.8 De quoi ai-je besoin pour programmer en C ?
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 ;-)
3.9 Quel(s) bouquin(s) ?
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 corriges 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.
(http://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 3.10).
Il existe aussi :
Engeln-Müllges G. & Uhlig F. (1996), Numerical Algorithms with C, Springer,
Berlin.
(fourni avec les sources et djgpp, pour plate-formes Wintel, sur CD).
3.10 Où trouver...
de la doc' ?
Là par exemple : http://cm.bell-labs.com/cm/cs/who/dmr/, c'est la page de
Denis Ritchie. Il y a aussi celle de Brian Kernighan :
http://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://ftp.ltam.lu/TUTORIEL/COURS-C/COURS-C.ZIP
http://www.enseignement.polytechnique.fr/profs/informatique/Eric.Goubault/poly/
cours.ps.gz
http://www.loria.fr/~mermet/CoursC/coursC.ps
http://www.enseignement.polytechnique.fr/profs/informatique/Jean-Jacques.Levy/poly/
polyx-cori-levy.ps.gz
http://www-inf.int-evry.fr/COURS/COURSC/
On lira aussi très attentivement :
ftp://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 : http://videoc.lip6.fr/
Les sources du bouquin de Braquelaire (dernière édition : la 3ème, 2ème
tirage...) :
http://dept-info.labri.u-bordeaux.fr/~achille/MPC-3/2T/MPC-3-2t.tar.gz
Les sources du bouquin de Loudon :
http://www.editions-oreilly.fr/archives/algoc.zip.
La bibliothèque standard : http://www.dinkum.com/htm_cl/
Le IOCCC est un concours de hackers qui récompense chaque année le pire
programme C :
http://www.ioccc.org/index.html
Un freezzine en anglais :
http://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://ftp.laas.fr/pub/ii/matthieu/tpp/tpp.ps.gz qui explique comment
utiliser make et
ftp://ftp.laas.fr/pub/ii/matthieu/cvs.ps.gz comment utiliser CVS.
la norme ?
Là : http://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 :
http://www.cssinfo.com/ncitsgate.html ou encore là
http://webstore.ansi.org/ansidocstore/product.asp?sku=ANSI%2FISO%2FIEC+9899%2D1999
(Merci à Antoine Leca).
la FAQ de comp.lang.c ?
Là : http://www.eskimo.com/~scs/C-faq/top.html
les pages des manuels Unix en français ?
Là : ftp://ftp.lip6.fr/pub/linux/french/docs/,
dans l'archive man-fr-x.x où x.x est le numéro de version (actuellement 0.8,
bientôt 0.9).
Le C et les CGI ?
Tout ce qui concerne le C à propos des CGI est là :
http://www.chez.com/nospam/cgi.html
Il y a aussi une FAQ ici :
http://www.htmlhelp.com/faq/cgifaq.html
(informations bienvenues à pascal.cabaud@wanadoo.fr)