Discussion :

[JPLAROCHE]

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

[Jacti]

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.

[pvincent]

Wikipedia:

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.

[destroyedlolo]

Salut,

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 ) 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 )

- 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.

- 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.

- 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.

- 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).

- 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
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 )

Mais bon, les gouts et les couleurs.

[Jacti]

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).

[Christophe]

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 :

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++

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.

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.

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.

[Guesset]

Bonjour 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

[Jacti]

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

De rien

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.

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.

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.

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.

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.

[destroyedlolo]

Salut,

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.

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.

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]

[edgarjacobs]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Jacti]

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.

[hurukan]

Pour moi le C est une bénédiction... j'adore ce langage.

Pour moi le C est un langage de programmation "middleware" (il existe des fonctions de bas et de haut niveau --> open() vs fopen() par exemple) et me convient parfaitement pour
créer les outils d'administration de mes systèmes Linux à la maison, au même titre que Perl.

Au niveau professionnel j'ai laissé tomber en 2008 du coup je me fies à ce que mes anciens collègues me disent: les conversations tournent souvent autour de Java, C++, ... dans le domaine
du Web j'entends parler de nodeJS... (pour les IoT a priori).

[Guesset]

Bonjour,

Attention scoop ! Le meilleur langage est celui qui permet de résoudre un type de problème avec confort et efficacité. Selon le problème et le développeur, le meilleur langage changera allègrement. Ce qui me paraît important est que le développeur diversifie ses techniques afin d'être plus à l'aise dans ses choix. S'il a seulement un marteau, tous les problèmes seront des clous.

• J'aime bien C pour son efficacité et son aptitude à faire des programmes optimisés et de grosses bêtises.
• J'aime bien C++ pour la richesse de ses bibliothèques qui permettent de traiter en peu de lignes des problèmes complexes avec une syntaxe hélas de plus en plus lourde (par exemple les cast).
• J'aime bien les assembleurs qui permettent paradoxalement d'utiliser des instructions de haut niveau de plus en plus implémentées dans les CPU. Elles correspondent chacune à plusieurs lignes de code en langage classique quasi impossible pour un compilateur de résumer en une seule instruction ASM. La plus simple est peut être la rotation binaire rot. Et puis ce qui est bien avec l'assembleur, c'est que, 3 mois plus tard, le code même bien documenté fait perdre beaucoup de cheveux.
• J'aime bien les langages de scripts et autres interprétés pour la rapidité de développement assortie d'une belle occupation mémoire et de lenteurs.
• J'aime bien Pascal presqu'aussi efficace que le C tout en étant heureusement (?) beaucoup plus verbeux.
• J'ai bien aimé le FORTAN pour ses tests arithmétiques (un test, trois sorties) et ses labyrinthes de goto calculés.
• J'ai regardé RUST qui apporte beaucoup de sécurité mais je n'ai pas envie de remettre des petites roues à mon vélo.
• J'ai bien aimé LISP, Prolog, Forth pour me sentir intelligent alors même que les résultats n'étaient pas là.
• Etc.

Tout ça pour dire qu'il y a des raisons pour aimer et haïr tous les langages. Que ces motifs sont en partie objectifs mais également subjectifs. Sur un même point objectif l'un mettra une pondération forte tandis que l'autre le négligera. C'est humain. Comme quelquefois l'exagération et la mauvaise fois.

Heureusement, à la fin, chacun sait qu'il a raison

Salutations

[Bktero]

@WhiteCrow : tu confonds métaprogrammation et optimisations du compilateur, avec cet exemple de factorielle.

Il y a effectivement des cas où le compilateur arrive à optimiser et peut calculer une valeur. Il remplace alors l'appel à la fonction par la valeur calculée. Mais ce n'est pas toujours possible, et en général la fonction sera vraiment être appelée au runtime.

En revanche, il y a des features en C++ pour "forcer" les calculs à la compilation. C'est le cas avec cette factorielle template. C'est une garantie que tout sera fait à la compilation et qu'aucun calcul sera fait au runtime.

Cet exemple particulier de factorielle ne permet pas de généraliser comme tu le fais.

PS : en C++ moderne, on utilisera plutôt une fonction constexpr ou consteval.

[WhiteCrow]

@WhiteCrow : tu confonds métaprogrammation et optimisations du compilateur, avec cet exemple de factorielle.

Il y a effectivement des cas où le compilateur arrive à optimiser et peut calculer une valeur. Il remplace alors l'appel à la fonction par la valeur calculée. Mais ce n'est pas toujours possible, et en général la fonction sera vraiment être appelée au runtime.

En revanche, il y a des features en C++ à "forcer" les calculs à la compilation. C'est le cas avec cette factorielle template. C'est une garantie que tout sera fait à la compilation et qu'aucun calcul sera fait au runtime.

Cet exemple particulier de factorielle ne permet pas de généraliser comme tu le fais.

PS : en C++ moderne, on utilisera plutôt une fonction constexpr ou consteval.

En effet, j'ai mis un tout petit peu de mauvaise foi dans mon argumentation, mauvaise foi que tu as relevée ^_^. Mais c'était aussi pour montrer que lorsqu'on ne voit le monde qu'avec un point de vue unique alors tous les exemples sont bons pour abonder dans le sens qu'on veut, y compris si ça n'a rien à voir

En revanche si le compilo arrive à prouver qu'une fonction est pure ou au minimum const, alors lorsqu'on demande les optimisations il le fera (dans la limite du raisonnable et du possible). C'est pour cela que que je rajoute aussi qu'il est préférable de donner au compilo les infos nécessaire pour l'aider à optimiser plutôt que d'essayer d'optimiser à la main, surtout en C moderne.

On pourra également remarquer que la métaprogrammation n'a en rien à voir avec une approche objet quelconque … ce n'est qu'un des mécanismes proposés de C++ hors OO.

[Jacti]

@WhiteCrow : tu confonds métaprogrammation et optimisations du compilateur, avec cet exemple de factorielle.

Il y a effectivement des cas où le compilateur arrive à optimiser et peut calculer une valeur. Il remplace alors l'appel à la fonction par la valeur calculée. Mais ce n'est pas toujours possible, et en général la fonction sera vraiment être appelée au runtime.

En revanche, il y a des features en C++ à "forcer" les calculs à la compilation. C'est le cas avec cette factorielle template. C'est une garantie que tout sera fait à la compilation et qu'aucun calcul sera fait au runtime.

Cet exemple particulier de factorielle ne permet pas de généraliser comme tu le fais.

PS : en C++ moderne, on utilisera plutôt une fonction constexpr ou consteval.

Je suis entièrement d'accord avec ton message. C'est une réponse parfaite y compris le Post Scriptum.

[wheel]

Il y a le HLA un langage assembleur avec POO dont le préprocesseur est doté de #if #while #for #print théoriquement il peut produire n'importe quelle source

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
     ?i := 0;
     #while( i < 5 )
 
          ?i := i + 1;
 
     #endwhile

[hurukan]

Bonjour,

Attention scoop ! Le meilleur langage est celui qui permet de résoudre un type de problème avec confort et efficacité. Selon le problème et le développeur, le meilleur langage changera allègrement. Ce qui me paraît important est que le développeur diversifie ses techniques afin d'être plus à l'aise dans ses choix. S'il a seulement un marteau, tous les problèmes seront des clous.

• J'aime bien C pour son efficacité et son aptitude à faire des programmes optimisés et de grosses bêtises.
• J'aime bien C++ pour la richesse de ses bibliothèques qui permettent de traiter en peu de lignes des problèmes complexes avec une syntaxe hélas de plus en plus lourde (par exemple les cast).
• J'aime bien les assembleurs qui permettent paradoxalement d'utiliser des instructions de haut niveau de plus en plus implémentées dans les CPU. Elles correspondent chacune à plusieurs lignes de code en langage classique quasi impossible pour un compilateur de résumer en une seule instruction ASM. La plus simple est peut être la rotation binaire rot. Et puis ce qui est bien avec l'assembleur, c'est que, 3 mois plus tard, le code même bien documenté fait perdre beaucoup de cheveux.
• J'aime bien les langages de scripts et autres interprétés pour la rapidité de développement assortie d'une belle occupation mémoire et de lenteurs.
• J'aime bien Pascal presqu'aussi efficace que le C tout en étant heureusement (?) beaucoup plus verbeux.
• J'ai bien aimé le FORTAN pour ses tests arithmétiques (un test, trois sorties) et ses labyrinthes de goto calculés.
• J'ai regardé RUST qui apporte beaucoup de sécurité mais je n'ai pas envie de remettre des petites roues à mon vélo.
• J'ai bien aimé LISP, Prolog, Forth pour me sentir intelligent alors même que les résultats n'étaient pas là.
• Etc.

Tout ça pour dire qu'il y a des raisons pour aimer et haïr tous les langages. Que ces motifs sont en partie objectifs mais également subjectifs. Sur un même point objectif l'un mettra une pondération forte tandis que l'autre le négligera. C'est humain. Comme quelquefois l'exagération et la mauvaise foi.

Heureusement, à la fin, chacun sait qu'il a raison

Salutations

J'adore ^^
Surtout

J'aime bien C pour son efficacité et son aptitude à faire des programmes optimisés et de grosses bêtises.
J'aime bien les assembleurs qui permettent paradoxalement d'utiliser des instructions de haut niveau de plus en plus implémentées dans les CPU. Elles correspondent chacune à plusieurs lignes de code en langage classique quasi impossible pour un compilateur de résumer en une seule instruction ASM. La plus simple est peut être la rotation binaire rot. Et puis ce qui est bien avec l'assembleur, c'est que, 3 mois plus tard (deux jours lol), le code même bien documenté fait perdre beaucoup de cheveux.

lol ^^

Je fais pas mal de bêtises aussi en Assembler (nasm).