Le langage de programmation C a 50 ans

Citation:

---

a cette époque mise à part assembleur et le basic et encore ce n'était pas le basic que tu connais, mais le gwbasic , puis le pascal , est arrivé le C (je parle sur PC)

---

Avant le C, il y a eu le FORTRAN précédé seulement par l'assembleur. Comme sont nom l'indique (Formula Translator) il a été conçu pour le calcul numérique et est utilisable sur PC (avec au début un compilateur vendu à prix d'or. Je n'entrerai pas dans le subtil distingo entre FORTRAN et Fortran.

Contrairement à ce que croit certains "he is still alive and in good wealth" même si il s'est de plus en plus orienté vers le calcul intensif sur super-calculateur.
Grâce à GNU, il fonctionne parfaitement sur PC (même si le compilateur Intel est bien plus performant quand il faut par paralléliser)

https://fr.wikipedia.org/wiki/Fortran
https://gcc.gnu.org/wiki/GFortranStandards

Citation:

---

Envoyé par pvincent

Avant le C, il y a eu le FORTRAN précédé seulement par l'assembleur. Comme sont nom l'indique (Formula Translator) il a été conçu pour le calcul numérique et est utilisable sur PC (avec au début un compilateur vendu à prix d'or. Je n'entrerai pas dans le subtil distingo entre FORTRAN et Fortran.

Contrairement à ce que croit certains "he is still alive and in good wealth" même si il s'est de plus en plus orienté vers le calcul intensif sur super-calculateur.
Grâce à GNU, il fonctionne parfaitement sur PC (même si le compilateur Intel est bien plus performant quand il faut par paralléliser)

https://fr.wikipedia.org/wiki/Fortran
https://gcc.gnu.org/wiki/GFortranStandards

---

désolé pas sur PC début des années 80 , sinon bien-sur qu'il y avait d'autre langage avant le C sur d'autre machine , mais à l'époque ou le C sur PC est sortie pendant une période de 3 ou 4 ans est sortie une flopée d'outil et de compilateur , de toute façon avec le dos, mais très vite avec windows 3.1 et os2 les choses ont évoluées et la vitesse d'évolution à été fulgurante

mais Fortran a pris son essor avec les premières feuilles de calcul avec Lotus mais pas sous dos
https://gilles-hunault.leria-info.un...r/histoire.htm

Citation:

---

Envoyé par JPLAROCHE

ps: j'ai commencé en informatique en 1976

---

J'ai obtenu ma maîtrise d'informatique en 1972...
Je connais à peu près toute l'histoire de l'informatique (je suis membre de l'ACM et de l'IEEE) et j'ai eu un Apple II pratiquement dès sa sortie en 1977. J'ai appris de nombreux langages avec celui-ci comme Lisp, Logo, Forth, Prologue.
En début de carrière (en 1973) je travaillais sur un gros IBM sous l'OS 360 en Cobol mais, en tant que spécialiste de la sémantique des langages de programmation je connais environ 50 langages de programmation et je peux facilement comparer.
A mon avis, le langage le plus complet est C++ mais difficile à maîtriser pour un débutant.
Mes langages favoris sont plutôt des langages fonctionnels et objets du style ocaml ou les versions de Java à partir de la 8 avec les expressions lambda.

Wikipedia:

Citation:

---

Projet lancé en 1954 et aboutissant à une première version en 1957, Fortran est le premier langage de programmation de haut niveau, suivi notamment par Lisp (1958), Algol (1958) et COBOL (1959). Il est le premier langage à être normalisé1, au milieu des années 60, et est devenu une norme ISO depuis Fortran 90.

---

C'est vrai qu'il était plutôt utilisé sur des "stations de travail", versions beaucoup plus chère qu'un simple PC mais outil de travail personnel..

Pour la petite histoire, quand IBM a lancé la dénomination "Personal Computer", il ne croyait tellement pas qu'on puisse s'en servir pour calculer que c'est la division 'Entry devices" qui l'a développé (la division reine étant "Mainframes") et sous traité l'OS à Microsoft. C'est un cas d'école d'erreur industrielle et IBM n'a survécut à la concurrence de Microsoft qu'au prix d'une reconfiguration drastique et douloureuse.

Salut,

Citation:

---

Envoyé par Jacti

du développement d'un compilateur de langage C avant même qu'il soit normalisé

---

Mon projet de fin d'étude début des années 90 portait sur un émulateur C (que j'ai mis d'ailleurs sur mon GIT ... 30 ans après, il se compile encore :mouarf:) et comme je m'étais mis comme cible Gcc sur Amiga et sur NetBSD, le CC natif de VAX/Ultrix et le Borland sur wintruc, j'ai soufere encore du manque de standardisation. Heureusement, elle s'est imposé par la suite (et comme je ne développe plus pour wintel, ca a encore enlever d'autres problèmes :ptdr:)

Citation:

---

Envoyé par Jacti

- Il n'est que faiblement typé donc pas du tout "secure" (conversions implicites)

---

il suffit d'activer les warning/erreurs qui vont bien des compilos modernes.

Citation:

---

Envoyé par Jacti

- On peut arriver à faire n'importe quoi avec les pointeurs en C grâce au "cast"

---

Il suffit juste de savoir ce que l'on fait. C'est sur que si on fait des cast a tord et a travers juste pour supprimer des warning sans chercher ce qu'il y a derriere ... ca ne peut que mal se finir.

Citation:

---

Envoyé par Jacti

- Le "switch/case" est une horreur car on est obligé d'utilisé break sans arrêt

---

??? Du coup, les do/done des shells doivent te donner des boutons, non ?
Je trouve au contraire que c'est très logique car ca indique que le bloc est terminé et permet de regrouper plusieurs conditions en un seul code lorsqu'on l'omet.

Citation:

---

Envoyé par Jacti

- Ler #define est une horreur car il oblige à faire des interactions dans le compilateur entre la phase d'analyse lexicale et syntaxique

---

"Oblige", pourquoi "Oblige". Quel je sache, rien ne t'impose d'envoyer des directives aux pré-processeurs.
A nouveau, très utile pour faire de la compilation conditionnelle et avoir binaire nettoyé de tout code de debug pour la prod (quand on sait bien l'utilisé et qu'on fait de vrais tes d'intégrations).

Citation:

---

Envoyé par Jacti

- L’équivalence pointeur/tableau qui a obligé Stroustrup a définir un « grigris » en C++ (la paire de crochet sur delete) pour indiquer qu’on veut détrire toutes les instances d’un tableau et pas seulement le premier élément.

---

Ben ouai, le C est un langage de plus bas niveau que la POO :D
Maintenant, si on reste en C, il suffit d'avoir une programmation propre et de passer soit par des pool mémoire, soit par des fonctions de gestions de la collection. C'est franchement basic.

Je développe depuis que j'étais ados, d'abord sur Amiga puis Unix et embarqué et je trouve beaucoup d'avantages par rapport aux autres langages que je trouve rapidement frustrant. Par exemple, les profs voulaient m'imposer le Pascal en DUT alors que je programmais depuis 3 ou 4 ans en C : quelles galères ! (et, a la fin, ils grognaient parce que je programmais en C pour tester mes algos puis ensuite je transformais en Pascal alors qu'ils voulaient le contraire :ptdr:)

Mais bon, les gouts et les couleurs.

Citation:

---

Envoyé par Ehma

Oui, ça j'en suis certain, le C ne disparaîtra pas, mais il sera réservé aux plus exigeants, experts, ... d'entre nous.

---

Et tout ceux qui font des divers (même si certains veulent basculer vers Rust ... mouai, va falloir amélioré le compilo alors), de l'embarqué, des damons et tout ce qui doit être léger et efficace.

Citation:

---

Envoyé par chrtophe

Là je connais pas, si tu peux développer ...

---

Je te donne l'adresse d'un document pdf : http://web.philo.ulg.ac.be/lasla/wp-...tementauto.pdf
Tu télécharges le document pdf pour pouvoir le manipuler sous Acrobat et tu vas à à partir de la page numérotée 100 (en fait 102/133 dans le pdf). Tu sauras tout sur les chaînes de caractères de longueur variable en PL/1.

Citation:

---

Envoyé par destroyedlolo

Salut,

"Oblige", pourquoi "Oblige". Quel je sache, rien ne t'impose d'envoyer des directives aux pré-processeurs.
A nouveau, très utile pour faire de la compilation conditionnelle et avoir binaire nettoyé de tout code de debug pour la prod (quand on sait bien l'utilisé et qu'on fait de vrais tes d'intégrations).

---

Je te parle de ce qu'on doit faire dans le compilateur pour traiter du #define, pas de ce que le programmeur C peut faire ou non.
Donc je répète que, dans le compilateur, on est obligé de traiter tous les cas et que ça impose des aller/retours entre la phase d'analyse lexicale et la phase d'analyse syntaxique ce qui est contraire à une architecture "propre" d'un compilateur.
Je ne nie pas que c'est très utile pour la compilation conditionnelle et que la notion de pré-processeur existait bien avant le langage C (en PL/1, par exemple).

Par ailleurs, concernant le switch/case, le s compilateurs C ne les transforment pas en if/else imbriqués mais construisent en interne un tableau avec des branchements directs sur les bon cas en construisant des pointeurs sur le code des différents cas ce qui est bien plus efficace que de dérouler, à l'exécution, les conditions de if/else imbriqués (c'est d'ailleurs comme cela qu'il faut programmer des automates à pile si on veut être efficace)
Pour la factorisation des cas semblables il aurait suffit d'inventer la syntaxe qui existe en ADA (liste des cas semblables séparés par des virgules).

Merci pour ma culture générale pour le retour sur PL/1.

J'ai regardé la fiche Wikipedia de PL/1. Voila ce qu'il faut en retenir :

Citation:

---

Son objectif était d'être universel et de pouvoir remplacer indifféremment les langages à destination scientifique, tels que FORTRAN et ALGOL, et le langage COBOL, plus adapté aux problèmes de comptabilité et de gestion
Ce langage avait beaucoup des caractéristiques de ce qui sera plus tard le C, et même déjà certaines du C++.

---

Le C est effectivement bas niveau. Si gérer une chaine comme un pointeur sur son 1er élément et/ou comme un tableau gène, que sa taille ne soit pas modifiable, dans ce cas, il vaut mieux utiliser string : en C++, si vous ne savez pas gérer/ne voulez pas gérer vous même la mémoire, utilisez C++

Citation:

---

dans le compilateur, on est obligé de traiter tous les cas et que ça impose des aller/retours entre la phase d'analyse lexicale et la phase d'analyse syntaxique ce qui est contraire à une architecture "propre" d'un compilateur.

---

c'est l’histoire compilation simple-passe ou multi-passe. Faire du multi-passe permet d'avoir des compilateurs plus performants qui multiplient les optimisations.

Citation:

---

Par ailleurs, concernant le switch/case, le s compilateurs C ne les transforment pas en if/else imbriqués mais construisent en interne un tableau avec des branchements directs sur les bon cas

---

un switch/case ou une liste de if..else, sont des sauts conditionnels. Au niveau du code intermédiaire généré par le compilateur, ça revient au même. Ca ne change pas le code généré mais plutôt la relecture du source C, c'est ce que je voulais dire.

Citation:

---

ce qui est bien plus efficace que de dérouler, à l'exécution

---

Dérouler à l’exécution peut être plus avantageux en terme de performance. Exemple : Le déroulage de boucles fait partie des optimisations d'un compilateur moderne. Pour ceux qui ne savent pas, un déroulage de boucle signifie que le compilateur va supprimer la boucle et la transformer en suite d'instructions répétées. Le code sera plus long en terme d'instructions exécutées, mais plus rapide en terme d’exécution. Le compilateur va jouer sur les spécifications du CPU de destination.

Bonjour chrtophe,

Citation:

---

Envoyé par chrtophe

....Un switch/case ou une liste de if..else, sont des sauts conditionnels. Au niveau du code intermédiaire généré par le compilateur, ça revient au même. Ca ne change pas le code généré mais plutôt la relecture du source C....

---

Si je dois remplacer un switch pas des if, j'aurais tendance à ne pas les mettre en liste mais en arborescence pour avoir un nombre moyen de tests en log2(nombre_de_cas) plutôt qu'en nombre_de_cas / 2 (hypothèse d'équipartition).

Je partage l'avis que les break dans les switch ne semblent pas dans la logique de concision du langage C. Les développeurs ont tellement l'habitude de mettre des break dans les switch qu'ils en mettent même dans le dernier case.
Virgule séparant des case ayant le même traitement et éventuellement un continue pour forcer le passage en séquence aurait ma préférence. C++ a gardé cela mais c'est moins choquant car la concision ne fait pas partie de ses objectifs.

Salut

Salut,

Citation:

---

Envoyé par Jacti

Je te parle de ce qu'on doit faire dans le compilateur pour traiter du #define, pas de ce que le programmeur C peut faire ou non.
Donc je répète que, dans le compilateur, on est obligé de traiter tous les cas et que ça impose des aller/retours entre la phase d'analyse lexicale et la phase d'analyse syntaxique ce qui est contraire à une architecture "propre" d'un compilateur.

---

Non, comme son nom l'indique, le préprocesseur fait son traitement AVANT que le compilo ne soit invoqué : il passe a ce dernier un source C "pure" ou les occurrences des #defines sont remplacés, les parties du code éludé (genre #if 0 ...) sont supprimés et pour certains vieux compilo noeux noeux, il y avait même le contenu des #include.
Certains préprocesseurs permettent d'accéder a ce code pure, il me semble que le préprocesseur de GCC le fait.
Il n'y a donc aucun aller retour : chacun fait sont taf.

Citation:

---

Envoyé par Jacti

Par ailleurs, concernant le switch/case, le s compilateurs C ne les transforment pas en if/else imbriqués mais construisent en interne un tableau avec des branchements directs sur les bon cas en construisant des pointeurs

---

A nouveau, c'est inexacte : l'optimiseur utilisera au choix des if/then ou des tables de redirections en fonction du nombres et de la distribution des valeurs a traitées. Dixit la doc de Gcc.

Citation:

---

Envoyé par Jacti

Pour la factorisation des cas semblables il aurait suffit d'inventer la syntaxe qui existe en ADA (liste des cas semblables séparés par des virgules).

---

Ca, on est bien d'accord. Idem avec la possibilité de faire des écarts [n,m]

gcc (et à ma connaisaance limitée) rien que lui a introduit le

Code:

---

1 2 3 4

switch( ) { case 1 ... 5: puts("in 1 to 5"); break;

---

Attention: les espaces après le '1' et avant le '5' sont nécessaires.

Oui, en effet.
Cependant, c'est une extension GCC : j'ai déjà donné dans le passé, je veux dire que j'utilisais des extensions qui ont été dépréciées du jour au lendemain (et qui évidemment étaient incompatible avec le reste du monde). Bref, meme si elles sont souvent bien pratique, j'évite maintenant :mrgreen:

Citation:

---

Envoyé par chrtophe

Merci pour ma culture générale pour le retour sur PL/1.

---

De rien

Citation:

---

Envoyé par chrtophe

J'ai regardé la fiche Wikipedia de PL/1. Voila ce qu'il faut en retenir :

---

Merci mais j'ai maintenu un compilateur PL/1 et je connais parfaitement ce langage.

Citation:

---

Envoyé par chrtophe

Le C est effectivement bas niveau. Si gérer une chaine comme un pointeur sur son 1er élément et/ou comme un tableau gène, que sa taille ne soit pas modifiable, dans ce cas, il vaut mieux utiliser string : en C++, si vous ne savez pas gérer/ne voulez pas gérer vous même la mémoire, utilisez C++

---

Je parle du compilateur de langage C et de la syntaxe merdique du C. J'ai développé un compilateur C et, dans ce cadre, le C++ et ses string n'ont rien à y faire. Je ne me place pas du côté des développeurs qui peuvent choisir tel ou tel langage. J'ai l'impression qu'on ne se comprend pas.

Citation:

---

Envoyé par chrtophe

c'est l’histoire compilation simple-passe ou multi-passe. Faire du multi-passe permet d'avoir des compilateurs plus performants qui multiplient les optimisations.

---

La compilation ne se fait JAMAIS en une seule passe. Un compilateur PL/1 a, en général, une quinzaine de passes. Dans un compilateur il y a au moins une phase d'analyse lexicale, une phase d'analyse syntaxique, une phase d'analyse sémantique, une phase éventuelle d'optimisation (voire plusieurs si on distingue optimisation locale et optimisation globale), une phase de génération de code.

Citation:

---

Envoyé par chrtophe

un switch/case ou une liste de if..else, sont des sauts conditionnels. Au niveau du code intermédiaire généré par le compilateur, ça revient au même. Ca ne change pas le code généré mais plutôt la relecture du source C, c'est ce que je voulais dire.

---

Non et non. Au niveau du code intermédiaire ça ne revient pas du tout au même. Ça change complètement le code généré puisqu'avec un switch on peut créer un tableau dont les éléments sont des pointeurs sur "le bon cas", ce qui est très efficace, alors qu'avec des if/else imbriqués on doit dérouler EN SÉQUENCEla suite des if/else ce qui peut perdre beaucoup de temps à l'exécution.

Citation:

---

Envoyé par chrtophe

Dérouler à l’exécution peut être plus avantageux en terme de performance. Exemple : Le déroulage de boucles fait partie des optimisations d'un compilateur moderne. Pour ceux qui ne savent pas, un déroulage de boucle signifie que le compilateur va supprimer la boucle et la transformer en suite d'instructions répétées. Le code sera plus long en terme d'instructions exécutées, mais plus rapide en terme d’exécution. Le compilateur va jouer sur les spécifications du CPU de destination.

---

On ne peut transformer la boucle en instructions répétées que si l'on connaît le nombre de tours de boucle, ce qui n'est pas le cas des boucles for avec des bornes qui sont des variables et non des constantes ou des boucles while. Cette transformation n'a plus vraiment cours, que dans les "vieux" compilateurs.

Citation:

---

Envoyé par destroyedlolo

Non, comme son nom l'indique, le préprocesseur fait son traitement AVANT que le compilo ne soit invoqué : il passe a ce dernier un source C "pure" ou les occurrences des #defines sont remplacés, les parties du code éludé (genre #if 0 ...) sont supprimés et pour certains vieux compilo noeux noeux, il y avait même le contenu des #include.
Certains préprocesseurs permettent d'accéder a ce code pure, il me semble que le préprocesseur de GCC le fait.
Il n'y a donc aucun aller retour : chacun fait sont taf.


A nouveau, c'est inexacte : l'optimiseur utilisera au choix des if/then ou des tables de redirections en fonction du nombres et de la distribution des valeurs a traitées. Dixit la doc de Gcc.


Ca, on est bien d'accord. Idem avec la possibilité de faire des écarts [n,m]

---

C'est justement parce que le préprocesseur "envoie" du code "pur" qu'il est nécessaire, dans l'implémentation du compilo, de faire des aller/retours. Il serait trop long et fastidieux de décrire pourquoi ici . Mais j'ai développé, avec mon équipe, un compilateur C depuis la page blanche et ces ordres préprocesseur sont une calamité tels qu'ils sont définis en C.

Pour les switch on fait TOUJOURS une table de redirection avec application de l'algorithme de traitement des matrices "creuses" quand le nombre de cas spécifiques est "petit" par rapport au nombre de cas total.
Entre parenthèse la doc de Gcc n'est pas la panacée et elle n'entre pas toujours dans tous les détails.

Citation:

---

Envoyé par destroyedlolo

Oui, en effet.
Cependant, c'est une extension GCC : j'ai déjà donné dans le passé, je veux dire que j'utilisais des extensions qui ont été dépréciées du jour au lendemain (et qui évidemment étaient incompatible avec le reste du monde). Bref, meme si elles sont souvent bien pratique, j'évite maintenant :mrgreen:

---

Tu as raison, il faut toujours éviter les extensions spécifiques liées à tel ou tel compilateur car, à la fin, on est toujours b*****.

Sachant qu'on réserve une zone mémoire Z avec la fonction malloc() et que cette même zone est libérée avec free(), il me semble que forcément, la taille de Z est stockée quelque part (à moins qu'une solution tordue comme celle du zéro utilisée par les chaînes de caractères ne soit mise en oeuvre par le compilateur).

Or un double free() produit une erreur qui oblige à faire tourner Valgrind pour la localiser.
Ce péril pourrai être facilement évité si on disposait d'une fonction pour tester la taille de Z, fonction qui pourrai aussi avoir bien d'autres usages.

Tout cela existe en Fortran ainsi qu'une gestion bien plus agréable des chaînes de caractères ou des tableaux. Cette gestion est basée sur la connaissance de la taille.

Bonjour,

C'est une drôle de discussion. En effet, la première version du langage C, le C K&R originel a 50 ans. Super, bon anniversaire.
Il a connu un énorme succès, a posteriori plus grand que les langages nés à la même époque ; son succès en a presque fait une lngua franca de l'informatique.
Mais C n'est pas qu'un langage, c'est un langage et une bibliothèque standard de fonctions. Le langage doit aussi son succès à cette bibliothèque ; elle est pour les systèmes de développement ce qu'est une épine dorsale à tous les chordés.
Le pire est que l'on peut utiliser un compilo (genre clang) avec une libc (genre musl) compilée avec un autre compilo (genre gcc). Et tout ça de manière transparente … la force d'une API et d'une ABI standardisées (même si pour l'ABI il en existe plusieurs).

Le succès se mesure non seulement au nombre d'implémentations pour des systèmes très différents mais aussi et surtout à sa capacité d'évolution et d'adaptation. Le C moderne est autre chose que le C K&R ; bien sûr il traîne des boulets depuis 50 ans mais a aussi réussi à se changer suffisamment pour continuer à être aussi bien un langage qu'un environnement de développement vivant et vivace.

J'ai l'impression que pour beaucoup d'entre vous le langage C n'a pas cessé d'être ce langage de bas niveau (= qui permet d'accéder sans restrictions à toutes les ressources du système cible d'une manière ou d'une autre) dont la simple lecture permet de s'imaginer quel sera le code assembleur produit sans trop d'efforts. Rien n'est plus faux maintenant sur les plateformes modernes et usuelles (hors baremetal).
Une tendance nette des dernières versions de C (99,11 et future 23) est clairement, en ce qui concerne le langage, de permettre au développeur d'aider le compilo à optimiser son code et non plus à proposer au compilo un code qui semble être optimisé.

La flexibilité reste telle qu'on peut se permettre de choisir une implémentation d'allocation sur le tas totalement différente de celle proposée par le standard et opter par exemple pour une gestion GC … rien ne l'empêche.

J'espère qu'`a terme C disparaîtra, c'est même inéluctable. Mais pour cela il faut une rupture et pas une évolution, c'est sur ce point que C++ a échoué et que Rust finira peut être par percer.

Citation:

---

Envoyé par WhiteCrow

J'espère qu'`a terme C disparaîtra, c'est même inéluctable. Mais pour cela il faut une rupture et pas une évolution, c'est sur ce point que C++ a échoué et que Rust finira peut être par percer.

---

"Tout passe, tout lasse, tout ce casse" comme la chanson le dit ... mais j'espère le plus tard possible pour le C qui match pas mal tout mes developpements perso (daemon, utilitaires, IoT, domotique, gestions de la télémétries de mes video, ...) ... et je n'ai pas trouvé de remplaçant.
En tout cas, ni python, encore moins Java qui sont trop glouton et lent pour ce que je fais.

Le C++ a beaucoup d'utilisations sur les outils complexes (genre GUI, traitements poussés qui gagnent a etre en POO) ... mais il a l'inconvénient de générer des exécutables lourds (et encore, j'utilise que rarement ses librairies standard) : il est donc complémentaire du C et non son remplacant.

Quand a Rust, je n'ai pas essayé : étant sous Gentoo, tout est recompilé sur mes machines et l'expérience que j'en ai pour Firefox ne m'incite pas a aller plus loin. Rien que la compilation de RustC est pénible (lourd, long, extrêmement groumant en mémoire, ...) et en va de même pour Firefox lui-même.

Citation:

---

Merci mais j'ai maintenu un compilateur PL/1 et je connais parfaitement ce langage.

---

Je m'en doute, l'information n'était pas à ta destination, mais aux autres lecteurs, qui comme moi ne connaissent pas cet ancien langage.

Citation:

---

La compilation ne se fait JAMAIS en une seule passe.

---

Dans ce cas pourquoi parle t'on de compilateurs simple passe et multipasse ?