Discussion:Programmation C/Introduction

C'est grâce à cette « optimisation » que, des années plus tard, on doit encore retenir des noms rébarbatifs comme strcpy(), strstr(), etc.

Ne devrait-on pas plutôt dire « C'est à cause de cette « optimisation » que, [...] » ? Dhenry 10 nov 2004 à 19:15 (UTC)

Bah c'était une petite pointe d'ironie :-) Thierry 18 nov 2004 à 23:45 (-5:00)

--

J'ai enlevé un lien externe qui semblait pointer vers une page bidon.Pfv2 18 aoû 2005 à 23:53 (UTC)

"adresses divisées par 4" ?

où la notion de type était inexistante et où les adresses étaient divisées par 4 (pour forcer l'alignement sur un mot mémoire)

• N'avoir qu'un seul type ne signifie pas ne pas en avoir du tout,
• les « adresses divisés par 4 » sous entend en fait un MODULO 4, c'est à dire les deux derniers bits à 0. Et encore cela n'est valable que pour les architecture 32 bits. Et en 1966, des machines 32 bits, je ne sais pas s'il y en avait beaucoup... 12, 18, 36, 60 bits, oui. 32 c'est peu probable.

Poil 21 sep 2005 à 21:06 (UTC)

J'ai supprimé le paragraphe incriminé, que je recopie ici au cas ou...

Ce langage est issu du langage BCPL (Basic Combined Programming Language), créé par Martin Richards en 1966. Il s'agissait d'un langage relativement rudimentaire, où la notion de type était inexistante et où les adresses étaient divisées par 4 (pour forcer l'alignement sur un mot mémoire). Malgré ces bizarreries, il a servi de base au système d'exploitation Tripos, qui deviendra plus tard AmigaOS. Guillaumito 21 sep 2005 à 21:23 (UTC)

Historique

Certains points de l'historique me semblent superflus dans l'introduction: parler des mots de 8 ou 16 bits du PDP-11, la limite des noms externes à 6 caractères... L'introduction devrait (à mon sens) être plus générale; les détails de l'évolution elle-même (ajout de types, contraintes...) pouvant faire l'objet d'un chapitre avancé dans le livre, qui détaillerait les différentes versions des langages, et les normes ou standards associés.

Par ailleurs, plus généralement, il manque une introduction comme celle du livre sur le C++, pour dire ce qu'on va faire dans le livre, préciser un plan, des prérequis... plutôt que de rentrer directement dans le vif du sujet.Alveric 15 juin 2006 à 18:21 (CEST)

Bon, j'ai modifié l'historique. Il y a juste le dernier paragaphe Le langage C est devenu extrêmement populaire sur les systèmes UNIX(...) qui devrait être déplacé, je pense, car il n'est pas lié à la normalisation. Mais je ne sais pas trop où le bouger... Alveric 26 juin 2006 à 18:11 (CEST)

Normes et API utilisées dans le livre

J'ai rajouté le paragraphe suivant:

Dans ce livre, nous étudierons surtout le langage C tel que défini dans les normes ISO citées au-dessus. La norme C99 n'étant pas implémentée par tous les compilateurs, et beaucoup de programmes existants étant développés en C90, les différences entre les deux normes seront indiquées à chaque fois que nécessaire. Toutefois, nous illustrerons certains chapitres avec des exemples d'extensions courantes qu'un développeur C peut rencontrer, en particulier concernant les fonctions qui ne sont pas fournies par la norme C elle-même.

L'état actuel du livre est assez bien décrit par ce paragraphe, il me semble, et je voulais bien préciser ce qui entre dans le cadre du livre et ce qui n'en est pas.

• Un simple constat fait que le C90 est encore très courant, donc un livre "pur C99" serait inadapté; mais un livre "pur C90" serait aussi obsolète. On justifie ainsi que certains chapitres feront référence aux deux versions du langage. Le faire ici évite de perdre le lecteur une fois qu'il arrivera sur un tel paragraphe.
• Win32, POSIX, MISRA-C ou des bibliothèques comme SDL peuvent très bien être utilisées ici, mais il faut bien préciser que ce n'est pas le but du livre que d'apprendre à programmer des interfaces graphiques (par exemple).

Des commentaires ? Alveric 27 juin 2006 à 12:18 (CEST)

Ah oui, excellent ajout, je n'aurais pas fait mieux! Pour le C99, c'est vrai que je n'ai pas rencontré beaucoup de programme qui utilisait la plupart de ses extensions (le moyau Linux est vraiment le seul qui me vienne en tête). Le C90 est encore largement dominant. Cela dit, les extensions C99 sont assez bien indiquées dans ce livre. Pour l'API Win32, SDL, POSIX, etc ... clairement elles n'ont rien à faire là, même ne serait-ce que quelques fonctions. Elles sont trop mamouthesques, il faudrait des centaines de pages pour les décrire chacune, même en ne se concentrant que sur l'essentiel. Mais bon, on peut rajouter des notes d'ouverture pour dire que si on veut ça, ben, il vaut mieux regarder dans telle ou telle API. Thierry Pierron 27 juin 2006 à 16:40 (CEST)

"Pour l'API Win32, SDL, POSIX, etc ... clairement elles n'ont rien à faire là, même ne serait-ce que quelques fonctions." Ce n'est pas toi qui voulait ajouter un chapitre sur les bibliothèques dynamiques ? ;)

Enfin bref, je ne pensais pas non plus à insérer des descriptions complètes de ces API (ce qui serait, je suis d'accord, complètement hors-sujet), mais plutôt à ta proposition sur les bibliothèques, dans le sens où on peut donner des exemples de fonctionnalités (pourquoi pas avec du code) qui nécessitent des API spécifiques (normalisées ou non) en plus du C ISO. Mais évidemment ces exemples doivent être limités à des chapitres précis; je pense plutôt en fin de livre, comme des ouvertures (annexe ?), du style "ce que ce livre ne vous a pas appris" ou "pour aller plus loin". Cela pourrait prendre la forme de listes de fonctionnalités génériques (communication entre processus, réseau, interface graphique...) pour lesquelles on indique les grandes API disponibles. Evidemment, on ne peut être exhaustif sur un tel chapitre... Alveric 27 juin 2006 à 18:00 (CEST)

Euh, je voulais rajouter un chapître qui explique comment les générer (et expliquer par la même occasion des problèmes ultra classiques). Pour générer des libs statiques ou dynamiques, il n'y a pas vraiment besoin de code particulier, il faut juste appeler d'autres commandes que le compilateur (c'est là la spécifité). Il existe effectivement des points d'entrées spécifiques pour faire des initialisations automatiques lorsqu'un processus ouvre la dll (DllMain sous Win32), mais bon, c'est facultatif et ou peut s'en passer facilement.

Autant pour moi, alors... Je pensais au chargement de bibliothèques au runtime (dlopen et autres). Si on se limite au lien pendant la compilation, alors évidemment c'est plus simple. Alveric