Apprendre la programmation en C.
+5
doom
Philippe
Petitagore
MattLA
Stauk
9 participants
Page 1 sur 3
Page 1 sur 3 • 1, 2, 3
Apprendre la programmation en C.
Bonjour. Je souhaite apprendre à programmer en C. Je créé donc ce fil pour discuter des éléments qui permettent de programmer en C. Le langage est simple, et proche de la machine. La première étape est donc d'avoir quelques notions d'assembleur, et de se familiariser avec la syntaxe du C, et les instructions assembleurs qu'un programme est susceptible d'utiliser. On pourrait essayer de liste ces instructions représentatives des comportements de base pour essayer d'aller au bout de la démarche.
Ce fil est créé pour discuter de tout ce qui est relatif à la (bonne) programmation en C. Le but est de fournir des liens vers des ressources, mais surtout réussir à obtenir une image aussi fine que possible de ce que serait une (ou plusieurs) bonne(s) façon de programmer des projets en utilisant ce langage ancien mais toujours en vogue.
Etant donné qu'il existe une probabilité non nulle que strictement personne sur ZC ne s'intéresse à ce sujet, ce fil a également la double vocation de me servir de bloc note au quotidien, dans cette entreprise d'atteindre un certain niveau de connaissance sur le sujet qui nous intéresse ici.
Ce fil est créé pour discuter de tout ce qui est relatif à la (bonne) programmation en C. Le but est de fournir des liens vers des ressources, mais surtout réussir à obtenir une image aussi fine que possible de ce que serait une (ou plusieurs) bonne(s) façon de programmer des projets en utilisant ce langage ancien mais toujours en vogue.
Etant donné qu'il existe une probabilité non nulle que strictement personne sur ZC ne s'intéresse à ce sujet, ce fil a également la double vocation de me servir de bloc note au quotidien, dans cette entreprise d'atteindre un certain niveau de connaissance sur le sujet qui nous intéresse ici.
Re: Apprendre la programmation en C.
Le management, vu par le logiciel libre (Linux Kernel).
https://www.kernel.org/doc/html/v4.10/process/management-style.html
Normes de codage du kernel linux (écrit en C)
https://www.kernel.org/doc/html/v4.10/process/coding-style.html
Le problème majeur à résoudre quand on programme :
https://testing.googleblog.com/2014/02/minimizing-unreproducible-bugs.html
Comment informer de façon générique sur l'erreur qui s'est produite (avec un simple appel du genre PANIC! quand le programme rencontre une erreur)
https://stackoverflow.com/questions/105659/how-can-one-grab-a-stack-trace-in-c
J'ai fait un petit test pour voir si on peut utiliser ce stacktrace pour déclarer une erreur. Mettons votre programme atteint un état dans lequel une précondition n'est pas remplie, on appelle alors une fonction dont le nom informe sur le problème, et paf, cette fonction appelle la fonction panic(), qui va produire la stackframe. On obtient un truc de ce genre, pour autant qu'on ait pensé à inclure les informations de debug (-rdynamic) qui vont nous fournir le nom des fonctions appellées.
Si on enlève le flag -rdynamic lors de la compilation, on obtient ça :
https://stackoverflow.com/questions/6338244/gcc-conditional-compilation
La directive -D envoyée à gcc lors de la compilation, nous permet de definir dynamiquement des constantes qui vont nous offrir la possibilité de rendre conditionnel la partie du code destinée à l'environnement de test. Par exemple "gcc main.c -o prog -DENV_TEST" compilera pour l'environnement de test, et "gcc main.c -o prog" (tout court) compilera pour l'environnement de production.
Si maintenant on compile puis exécute (environnement de test):
Si maintenant on compile puis exécute (environnement de prod):
https://www.kernel.org/doc/html/v4.10/process/management-style.html
Normes de codage du kernel linux (écrit en C)
https://www.kernel.org/doc/html/v4.10/process/coding-style.html
Le problème majeur à résoudre quand on programme :
https://testing.googleblog.com/2014/02/minimizing-unreproducible-bugs.html
Comment informer de façon générique sur l'erreur qui s'est produite (avec un simple appel du genre PANIC! quand le programme rencontre une erreur)
https://stackoverflow.com/questions/105659/how-can-one-grab-a-stack-trace-in-c
J'ai fait un petit test pour voir si on peut utiliser ce stacktrace pour déclarer une erreur. Mettons votre programme atteint un état dans lequel une précondition n'est pas remplie, on appelle alors une fonction dont le nom informe sur le problème, et paf, cette fonction appelle la fonction panic(), qui va produire la stackframe. On obtient un truc de ce genre, pour autant qu'on ait pensé à inclure les informations de debug (-rdynamic) qui vont nous fournir le nom des fonctions appellées.
- Code:
./prog(panic+0x1f)[0x557a1ffe194f]
./prog(this_is_an_error+0xe)[0x557a1ffe197c]
./prog(main+0xe)[0x557a1ffe198d]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fa0bb5982b1]
./prog(_start+0x2a)[0x557a1ffe182a]
- le programme C:
- Code:
// https://linux.die.net/man/3/backtrace_symbols_fd
// https://stackoverflow.com/questions/105659/how-can-one-grab-a-stack-trace-in-c
// gcc -rdynamic main.c -o prog
#include <execinfo.h>
#include <unistd.h>
void panic(){
int j, nptrs;
void *buffer[20];
nptrs = backtrace(buffer, 20);
backtrace_symbols_fd(buffer, nptrs, STDOUT_FILENO);
}
void this_is_an_error(){
panic();
}
int main(){
this_is_an_error();
return 0;
}
Si on enlève le flag -rdynamic lors de la compilation, on obtient ça :
- Code:
./prog(+0x745)[0x561ea61a6745]
./prog(+0x5eb)[0x561ea61a65eb]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f61c6e2b2b1]
./prog(+0x62a)[0x561ea61a662a]
https://stackoverflow.com/questions/6338244/gcc-conditional-compilation
La directive -D envoyée à gcc lors de la compilation, nous permet de definir dynamiquement des constantes qui vont nous offrir la possibilité de rendre conditionnel la partie du code destinée à l'environnement de test. Par exemple "gcc main.c -o prog -DENV_TEST" compilera pour l'environnement de test, et "gcc main.c -o prog" (tout court) compilera pour l'environnement de production.
- Code:
//https://stackoverflow.com/questions/6338244/gcc-conditional-compilation
// gcc main.c -o prog -DENV_TEST ---> environnement de test
// gcc main.c -o prog ---> environnement de production
#include <stdio.h>
int main (){
#ifdef ENV_TEST
printf("Environnement de TEST\n");
#else
printf("Environnement de PRODUCTION\n");
#endif
return 0;
}
Si maintenant on compile puis exécute (environnement de test):
- Code:
>gcc main.c -o prog -DENV_TEST
>./prog
>Environnement de TEST
Si maintenant on compile puis exécute (environnement de prod):
- Code:
>gcc main.c -o prog
>./prog
>Environnement de PRODUCTION
Re: Apprendre la programmation en C.
Une page dont l'objet est de promouvoir des normes de programmation.
https://wiki.sei.cmu.edu/confluence/display/c/Introduction
Il y a une page dédiée au C
https://wiki.sei.cmu.edu/confluence/display/c/SEI+CERT+C+Coding+Standard
https://wiki.sei.cmu.edu/confluence/display/c/Introduction
Il y a une page dédiée au C
https://wiki.sei.cmu.edu/confluence/display/c/SEI+CERT+C+Coding+Standard
Re: Apprendre la programmation en C.
je veux m'y mettre aussi
MattLA- Messages : 67
Date d'inscription : 27/08/2017
Re: Apprendre la programmation en C.
Bonjour,
Je n'ai plus touché au C depuis une bonne vingtaine d'année mais je peux te recommander un bouquin(Moins de 200 pages) pour comprendre les mécaniques de bases du C en particulier toute la partie gestion de la mémoire. Il permettait de rentrer très vite dans les spécificités du C et des erreurs classiques.
Il faut être cependant à l'aise avec les notions de lisibilité, de valeur, d'adressage, de pointeur et de structure.
C'est l'un des meilleurs langage que je connaisse pour faire ce que l'on veut avec des perfos proche de l'assembleur quand on connait bien le compilateur avec lequel on développe.
L'inconvénient c'est qu'il peut être piégeur et là çà devient coton.
Bon courage
La langage C de Dominique Galland - Editions Dunod
Je n'ai plus touché au C depuis une bonne vingtaine d'année mais je peux te recommander un bouquin(Moins de 200 pages) pour comprendre les mécaniques de bases du C en particulier toute la partie gestion de la mémoire. Il permettait de rentrer très vite dans les spécificités du C et des erreurs classiques.
Il faut être cependant à l'aise avec les notions de lisibilité, de valeur, d'adressage, de pointeur et de structure.
C'est l'un des meilleurs langage que je connaisse pour faire ce que l'on veut avec des perfos proche de l'assembleur quand on connait bien le compilateur avec lequel on développe.
L'inconvénient c'est qu'il peut être piégeur et là çà devient coton.
Bon courage
La langage C de Dominique Galland - Editions Dunod
Invité- Invité
Re: Apprendre la programmation en C.
message censuré
Dernière édition par Roger le Dim 17 Déc 2017 - 1:53, édité 1 fois
Invité- Invité
Re: Apprendre la programmation en C.
@Roger : lire les normes (que j'ai mis en lien plus haut) c'est pas mal pour se faire une idée des bonnes pratiques, et des pièges à la con. Exemple de programme avec un comportement étrange (si vous voulez tester le niveau d'expertise de quelqu'un en C, j'imagine que ça peut faire l'objet d'une question pour départager).
Qu'est ce que le programme "prog" suivant sort sur stdout, lorsqu'il est compilé avec une commande telle que
"gcc -trigraphs main.c -o prog" ?
main.c
Qu'est ce que le programme "prog" suivant sort sur stdout, lorsqu'il est compilé avec une commande telle que
"gcc -trigraphs main.c -o prog" ?
main.c
- Code:
#include <stdio.h>
int main(){
int a=1;
// Does this print 2??/
a++;
printf("La valeur de a est %i\n",a);
return 0;
}
- ./prog ...:
La valeur de a est 1
Re: Apprendre la programmation en C.
message censuré
Dernière édition par Roger le Dim 17 Déc 2017 - 1:53, édité 1 fois
Invité- Invité
Re: Apprendre la programmation en C.
Roger a écrit:
Commencer la programmation avec du C, c'est du suicide. Il faut toujours apprendre avec un souci de rigueur, donc avec des outils bien fondés, avec une sémantique univoque et bien maîtrisée. Cela permet de plus d'apprendre ce qu'est une sémantique, ce que la quasi-totalité des programmeurs ignore (un désastre en pratique; les audits annuels du Standish Group pointe du doigt la baisse de qualité des logiciels et leur coût ahurissant pour la collectivité).
Je me suis un peu documenté sur les langages de programmation, aucun à ma connaissance ne rempli tes critères.
Re: Apprendre la programmation en C.
message censuré
Dernière édition par Roger le Dim 17 Déc 2017 - 1:53, édité 1 fois
Invité- Invité
Re: Apprendre la programmation en C.
J'avais regardé COQ bien sûr, en particulier au moment de la mode de l'homotopy type theory. J'avais aussi jeté un oeil sur Forth. La raison pour laquelle j'ai choisis C, c'est son coté minimaliste en comparaison des alternatives qui pourraient remplir le même office. J'ai besoin d'un langage qui me laisse ouvert l'option d'accéder aux aspects bas niveau.
Les nouveaux langages tel que rust, ou même C++ font appel aux patterns de la programmation fonctionnelle. L'ennui c'est que ça demande un certain investissement pour en maîtriser le vocabulaire. Par comparaison le C demande 6h chrono en main pour en faire le tour. Easy to learn, hard (impossible) to master. Bien sûr C a des défauts, et je pense qu'il y aurait matière à en conserver les forces, tout en modernisant un peu la chose. Là aussi des langages comme Rust et Go (ou même Java) ont justement cette ambition, mais à force de se perdre dans des considérations théoriques, on s'éloigne de la force majeure du C : le coté pragmatique et extrêmement léger du langage.
Un langage de programmation qui demande plus de 6h avant de pouvoir être lu et utilisé, est un mauvais langage de mon point de vue. Pas dans l'absolu sans doute, mais simplement du fait qu'on a absolument besoin d'avoir un tel langage avec des fondations solides, avant d'envisager quelque chose plus complexe. Du moins à mon sens. Le C avec ses macros, reste un langage compliqué et mal commode. Mais tout bien pesé, c'est celui qui sur ma check-list a le meilleur score pour le moment.
L'idéal serait que je créé mon propre langage, mais avant je suis convaincu que d'avoir une solide expérience concrète autour du C, avec à minima un projet de moyenne de taille bien ficelé est nécessaire. Et pour le peu que j'ai pu en voir, un langage même extrêmement bien conçu pour remplacer C, a peu de chance de réussir à prendre sans un gros Label bien juteux pour attirer les foules. Rust est soutenu par Mozilla, sous license open-source, et a le vent en poupe. Pourtant plus je le contemple, moins je trouve qu'il me convient pour remplacer C. J'ai le sentiment qu'il finira par remplacer C++ par contre. Et j'espère qu'un concurrent sérieux au C apparaîtra, pour ne pas laisser les futurs générations avec un truc aussi lourd et inélégant que Rust. Enfin ce n'est probablement pas de mon ressort.
Maintenant je veux bien qu'on revienne au sujet du fil.
Les nouveaux langages tel que rust, ou même C++ font appel aux patterns de la programmation fonctionnelle. L'ennui c'est que ça demande un certain investissement pour en maîtriser le vocabulaire. Par comparaison le C demande 6h chrono en main pour en faire le tour. Easy to learn, hard (impossible) to master. Bien sûr C a des défauts, et je pense qu'il y aurait matière à en conserver les forces, tout en modernisant un peu la chose. Là aussi des langages comme Rust et Go (ou même Java) ont justement cette ambition, mais à force de se perdre dans des considérations théoriques, on s'éloigne de la force majeure du C : le coté pragmatique et extrêmement léger du langage.
Un langage de programmation qui demande plus de 6h avant de pouvoir être lu et utilisé, est un mauvais langage de mon point de vue. Pas dans l'absolu sans doute, mais simplement du fait qu'on a absolument besoin d'avoir un tel langage avec des fondations solides, avant d'envisager quelque chose plus complexe. Du moins à mon sens. Le C avec ses macros, reste un langage compliqué et mal commode. Mais tout bien pesé, c'est celui qui sur ma check-list a le meilleur score pour le moment.
L'idéal serait que je créé mon propre langage, mais avant je suis convaincu que d'avoir une solide expérience concrète autour du C, avec à minima un projet de moyenne de taille bien ficelé est nécessaire. Et pour le peu que j'ai pu en voir, un langage même extrêmement bien conçu pour remplacer C, a peu de chance de réussir à prendre sans un gros Label bien juteux pour attirer les foules. Rust est soutenu par Mozilla, sous license open-source, et a le vent en poupe. Pourtant plus je le contemple, moins je trouve qu'il me convient pour remplacer C. J'ai le sentiment qu'il finira par remplacer C++ par contre. Et j'espère qu'un concurrent sérieux au C apparaîtra, pour ne pas laisser les futurs générations avec un truc aussi lourd et inélégant que Rust. Enfin ce n'est probablement pas de mon ressort.
Maintenant je veux bien qu'on revienne au sujet du fil.
Re: Apprendre la programmation en C.
cool ce topic on apprend plein de brols
que les langages math oriented ont fait du chemin pour finir dans une intégration, moi qui pensait que python était le plus usité
que les langages de nouvelles générations étaient moins sophistiqués que les anciens, à vrai dire je n'ai jamais très bien compris cette multiplication infernale de langage
qui maitrise ?
apprendre le c en quelques heures ? franchement sans back ground préalable dans d'autres langages, principes et connaissance hardware et os je ne pense pas que ce soit possible
d'ailleurs c'est pas très compliqué des programmeurs système il y en a en fait très peu
le vrai truc en prog quelque soit le langage c'est d'avoir une vision de l'ensemble qu'on veut pondre, donc en gros répondre à la question de base, c'est pour faire quoi ?
et apprendre un nouveau langage de prog tous les deux ans pffff merde à la fin
dans la série j'y pige rien mais je vous met le lien de l'analyseur de codes
https://pmd.github.io/
et un cours basique
https://openclassrooms.com/courses/apprenez-a-programmer-en-c
pour le fun dans la foulée
https://openclassrooms.com/old-courses-pdf
que les langages math oriented ont fait du chemin pour finir dans une intégration, moi qui pensait que python était le plus usité
que les langages de nouvelles générations étaient moins sophistiqués que les anciens, à vrai dire je n'ai jamais très bien compris cette multiplication infernale de langage
qui maitrise ?
apprendre le c en quelques heures ? franchement sans back ground préalable dans d'autres langages, principes et connaissance hardware et os je ne pense pas que ce soit possible
d'ailleurs c'est pas très compliqué des programmeurs système il y en a en fait très peu
le vrai truc en prog quelque soit le langage c'est d'avoir une vision de l'ensemble qu'on veut pondre, donc en gros répondre à la question de base, c'est pour faire quoi ?
et apprendre un nouveau langage de prog tous les deux ans pffff merde à la fin
dans la série j'y pige rien mais je vous met le lien de l'analyseur de codes
https://pmd.github.io/
et un cours basique
https://openclassrooms.com/courses/apprenez-a-programmer-en-c
pour le fun dans la foulée
https://openclassrooms.com/old-courses-pdf
Invité- Invité
Re: Apprendre la programmation en C.
message censuré
Dernière édition par Roger le Dim 17 Déc 2017 - 1:54, édité 1 fois
Invité- Invité
Re: Apprendre la programmation en C.
Roger a écrit:Php, Python, C, C++, Java, Javascript => poubelle.
J'aime tes propos nuancés...
Si je mets Javascript à la poubelle, il ne me reste absolument rien pour faire tourner un algorithme si simple soit-il dans une page web... et c'est quand même un peu limitant en l'an 2017. Sauf à envisager la conversion automatique en Javascript d'une démarche logique définie avec un autre langage. Je me suis laissé dire qu'on pouvait faire ça avec du OCaml, mais ça ne m'a vraiment pas l'air d'être une pratique très répandue. Tu fais ça, toi?
PHP est vraiment très moche, et à mon avis c'est un très mauvais outil d'apprentissage. Cela dit, quand on y vient après s'être bien formé avec autre chose, ça marche quand même très bien, au point de faire tourner Wordpress et Symfony... ce qui n'est peut-être pas tout à fait négligeable.
Si tu connais un meilleur langage d'initiation que Python, tu m'intéresses parce que tu mets vraiment la barre très haut! Soit dit en passant, si on part d'un cerveau vierge qui n'a jamais touché à la programmation impérative, on peut tout à fait lui apprendre la programmation fonctionnelle en employant Python (qui est multi-paradigmes). Si on n'a pas la chance d'avoir un cerveau vierge, Haskell est plus adapté... mais l'expérience démontre quand même que très très peu de gens déjà formés à la programmation impérative arrivent à accrocher avec Haskell. Les surdoués peuvent essayer, j'ai bien peur que pour les autres il soit plus réaliste de laisser tomber (et d'en rester à cette bonne vieille programmation impérative, de préférence avec quelques idées sur le paradigme objets). Pour les gens normaux voire brillants, Python reste à ma connaissance le meilleur point d'entrée: facile, plutôt rigoureux, beaucoup plus puissant qu'on le croirait, et tout de suite amusant (principale qualité d'un outil d'apprentissage, à mon avis).
Java représente un certain état de l'art, et à mon avis c'est un bon langage pour les pas surdoués. Pour les surdoués, c'est frustrant, parce que c'est carrément pas marrant du tout. Si vous faites du Java pour gagner votre croûte, je vous plains. Si vous vous éclatez en faisant du Java, je m'en réjouis pour vous mais je vous signale quand même que vous êtes méchamment pas normal.
C, c'est le Vietnam: quand on en revient vivant (ce qui est possible mais pas systématique), on n'a plus peur de grand-chose, et notamment pas de l'indébogable. Et par ailleurs, c'est quand même bien de savoir écrire des listings qui tournent vite. C n'est pas le seul à savoir le faire, mais assurément, lui, il sait -- et quand on y arrive, c'est fun. Ceux qui détestent C devraient avoir l'honnêteté d'admettre que c'était trop fort pour eux (ce qui ne veut pas dire qu'ils ne puissent rien faire d'autre).
C++, c'est l'engagement de toute une vie, il faut entrer en C++ comme on entre au couvent: avec l'idée que durant toute sa vie il faudra se pencher sur les saintes écritures (les docs, les normes, les librairies). Moi, je m'y suis mis trop tard et de toute façon je ne pense pas que ça m'aurait plu... mais ce sont nettement les programmeurs C++ qui m'ont toujours le plus impressionné: total respect, sauf s'ils travaillent chez Microsoft, auquel cas ce sont de toute évidence des nuls.
Dernière édition par Petitagore le Dim 19 Nov 2017 - 0:10, édité 1 fois (Raison : Symfony, pas Symphony)
Re: Apprendre la programmation en C.
Roger a écrit:
Le C n'est pas minimaliste du tout: la dernière norme fait 683 pages !
Bah écoute, quand on peut écrire un compilateur en 100Ko tout inclus, je dis que c'est minimaliste.
https://bellard.org/tcc/
SMALL! You can compile and execute C code everywhere, for example on rescue disks (about 100KB for x86 TCC executable, including C preprocessor, C compiler, assembler and linker).
FAST! tcc generates x86 code. No byte code overhead. Compile, assemble and link several times faster than GCC.
UNLIMITED! Any C dynamic library can be used directly. TCC is heading torward full ISOC99 compliance. TCC can of course compile itself.
TinyCC : 859000 lines/second 29.6 Mb/s
(bon Bellard est un génie, n'empêche que ça montre que c est un langage simple. Même un génie ne pas réaliser plus que l'impossible)
Ptet tu confonds C et C++ ??
Dernière édition par Stauk le Sam 18 Nov 2017 - 21:13, édité 1 fois
Re: Apprendre la programmation en C.
Petitagore a écrit:
Si je mets Javascript à la poubelle, il ne me reste absolument rien pour faire tourner un algorithme si simple soit-il dans une page web... et c'est quand même un peu limitant en l'an 2017. Sauf à envisager la conversion automatique en Javascript d'une démarche logique définie avec un autre langage. Je me suis laissé dire qu'on pouvait faire ça avec du OCaml, mais ça ne m'a vraiment pas l'air d'être une pratique très répandue. Tu fais ça, toi?
Ce n'est pas tout à fait exact. Tu peux écrire tes programmes pour navigateurs en C, C++, Rust, et probablement dans pleins d'autres langages.
http://kripken.github.io/emscripten-site/
Demo (pour le framework de creation de jeux vidéo Unity) :
http://webassembly.org/demo/Tanks/
Aujourd'hui les navigateurs supportent webassembly, si tu as une version récente de ton navigateur.
https://medium.com/@mbebenita/webassembly-is-30x-faster-than-javascript-c71ea54d2f96
Re: Apprendre la programmation en C.
C'est intéressant, Stauk, merci de me l'apprendre. Ca m'a quand même l'air d'être encore à l'état de prototype.
Re: Apprendre la programmation en C.
Petitagore a écrit:C'est intéressant, Stauk, merci de me l'apprendre. Ca m'a quand même l'air d'être encore à l'état de prototype.
Ca fonctionne bien pour créer des (petits) programmes non connectés. Je n'ai pas essayé avec des programmes connectés pour le moment, mais ça ne m'a pas paru aller de soi. De même l'intégration mixte C/javascript n'est pas nécessairement aussi aisée que de compiler un programme C et de l’exécuter tel quel. Par contre la techno de compilation elle est parfaitement mature (elle fonctionne parfaitement avec asm.js [l'ancienne façon d'avoir du code javascript très optimisé pour cpu] et webassembly), ce qui manque c'est essentiellement une intégration des couches réseaux, qui sont assez différentes en programmation traditionnelle élémentaire (sockets) et en Javascript (http ou WebRTC qui sont beaucoup plus lourds qu'une simple socket et pas vraiment utilisés ailleurs que pour des applications webs). C'est à peu près l'équivalent de Wine en terme de maturité, il y aura toujours des ajustements à faire, et des incompatibilités, mais un programme standard ne rencontre pas de difficultés d’exécution, tant qu'il ne va pas chercher des fonctionnalités exotiques (genre des intrinsics).
Les programmes émis par les compilateurs gagneraient à être plus compacts par contre, étant donné qu'en général tu fais transiter l'intégralité de ton programme par le réseau avant son exécution. L'absence de compatibilité des abstractions réseaux rend difficile la modularité de chargement (un programme qui charge très vite son noyaux, et télécharge le reste tout en restant utilisable). Je ne suis pas très sûr de comment le versionning est géré non plus, charger intégralement le même programme à chaque fois qu'une même page est rafraîchie n'est pas idéal étant donné la lourdeur naturelle qui va croissante des programmes qu'on utilise couramment. Par exemple word doit faire quelques gigas.
En résumé la technologie fonctionne parfaitement, mais il manque les frameworks adaptés. L'ensemble évolue assez vite, et pas grand monde ne semble douter que c'est bien là qu'est le web de demain.
Re: Apprendre la programmation en C.
Stauk a écrit:... J'ai besoin d'un langage qui me laisse ouvert l'option d'accéder aux aspects bas niveau.
...Par comparaison le C demande 6h chrono en main pour en faire le tour. Easy to learn, hard (impossible) to master.
Hello Stauk,
Attention à trop d'enthusiasme
La base du C est effectivement facile et très rapide à comprendre. La manipulations des données en mémoire c'est cool mais çà va commencer à faire chauffer le cerveau quand il y des soucis avec des structures de données complexes. L'adressage des fonctions peut être rock n roll mais là tu pars dans le coeur de la bête.
Si tu décides de taper dans le bas niveau, tu devras passer quelques heures à étudier les architectures des systèmes pour définir l'architecture du soft que tu développes. Sinon tu risques de t'arracher les cheveux lors du portage du code si les niveaux d'abstraction sont mal défini.
Le C est un jeu intellectuel passionant mais n'est pas forcément adapté à toutes les problématiques. Par contre si tu rentres dedans, la légèreté et les performances de traitement sont au rendez-vous et si la programmation systèmes te passionne, tu n'auras plus trop de limite. Mais c'est beaucoup beaucoup de temps.
Si l'ojectif est une appli traditionnelle, tu peux t'amuser à faire un mix java/C. Le Java assure un dév rapide des couches haute de présentation et un portage rapide et le C pour toutes les tâches de fond. Si tu es Microsoft addict, un VisualTruc fera très bien l'affaire en remplacement du Java
Amuses toi bien et penses à faire un plein de café !
edit : ortho
Invité- Invité
Re: Apprendre la programmation en C.
message censuré
Dernière édition par Roger le Dim 17 Déc 2017 - 1:54, édité 1 fois
Invité- Invité
Re: Apprendre la programmation en C.
message censuré
Dernière édition par Roger le Dim 17 Déc 2017 - 1:55, édité 1 fois
Invité- Invité
Re: Apprendre la programmation en C.
Roger, je crains que tu aies interprété le titre du fil comme « [apprendre la programmation] en C », alors que l'intention de l'auteur me semble plutôt : « apprendre [la programmation en C] », si tu vois ce que je veux dire.Roger a écrit:Quand on veut faire le l'algorithmique sérieuse, on ne se met pas des boulets aux pieds. On a autre chose à faire que de gérer les malloc et les free, par exemple. On a d'autres soucis que d'assurer à la main la compatibilité des types de données atomiques.
À part ça, je suis d'accord avec à peu près tout ce que tu as écrit ; comme toi pour apprendre à programmer (en général) je recommanderais un langage « venant des maths » donc fonctionnel, probablement Haskell, ou OCaML. Et pour goûter à de l'impératif Forth bien meilleur que C. Plus de l'assembleur si besoin.
Malheureusement, en informatique comme ailleurs, les choses à la mode sont rarement les meilleures, et les standards industriels le sont souvent pour de mauvaises raisons (économie capitaliste, par ex.).
Re: Apprendre la programmation en C.
Philippe a écrit:pour apprendre à programmer (en général) je recommanderais un langage « venant des maths » donc fonctionnel, probablement Haskell, ou OCaML.
Je ne connais pas OCaml et donc je n'en dirai rien. Mais j'ai tâté de Haskell, ça m'a beaucoup plu mais j'en ai quand même retiré la conviction que je n'aurais jamais pu me mettre à la programmation avec lui, à cause de sa façon psycho-rigide de refuser les entrées-sorties dans tout ce qui est vraiment conçu selon une démarche fonctionnelle. Quand on est un débutant, on se trompe: on écrit + au lieu de -, sin au lieu de cos, on oublie qu'il y a dix éléments dans une liste allant de 0 à 9... les pièges à con sont innombrables et le seul moyen de comprendre pourquoi le résultat produit n'est absolument pas celui auquel on s'attendait, c'est de demander à son propre listing d'afficher des résultats intermédiaires -- ce que Haskell n'autorise qu'au prix d'une refonte considérable du code, alors que dans tout langage impératif on peut coller des print ou printf à tout moment et n'importe où. Vraiment, je ne crois pas qu'un débutant puisse s'en passer.
Par ailleurs, s'il fallait vraiment avoir une démarche mathématique pour programmer correctement, alors tous les bons programmeurs auraient été des bêtes en maths, et tous les bons matheux auraient au moins une connaissance minimale de la programmation. L'une et l'autre chose sont fausses, et il faut vraiment n'avoir jamais fréquenté ni des informaticiens ni des matheux pour en douter.
Qu'on le veuille ou non, la machine de Turing a un fonctionnement chronologique et non strictement logique: dans tout traitement il y a un début (une initialisation), un milieu (un moment où "ça mouline") et une fin (le renvoi d'un résultat). La programmation impérative n'a aucun besoin de se torturer pour aboutir à ce découpage en début, milieu et fin, et ça ne pose donc aucun problème à aucun débutant. Au contraire (et c'est ce que j'ai été ravi d'apprendre en Haskell), la clé de la compréhension de la démarche fonctionnelle, c'est de ne plus penser le programme de façon chronologique, de tout penser en termes d'égalités au sens mathématique du terme... c'est-à-dire quelque chose de complètement immuable, de pas du tout évolutif. Par certains côtés, c'est beaucoup plus élégant; mais c'est des maths, la machine de Turing, elle, elle mouline bel et bien des instructions dans un ordre chronologique, et l'application d'une démarche valorisant les égalités immuables sur une machine ayant un fonctionnement chronologique se traduit bien par l'ajout, d'emblée, d'une belle grosse couche d'abstraction.
Or, par définition, le débutant en programmation n'est pas très habitué à grimper les niveaux d'abstraction, le but de son apprentissage est justement en grande partie de l'y habituer, et ça peut prendre un certain temps. Avec la programmation fonctionnelle, on lui demande de commencer par monter tout de suite une marche d'abstraction passablement haute... et dans les faits, c'est assez élitiste: c'est peut-être à la portée de beaucoup de zèbres (à mon avis, vraiment pas tous), mais tous les débutants ne peuvent pas y arriver.
Cela dit, la notion de pointeur, qu'il faut absolument se coltiner en C, est elle-même une marche d'abstraction carrément très très haute à faire grimper au débutant, et donc ça m'inspire la même remarque: le C premier langage, c'est carrément élitiste.
Il faut permettre aux programmeurs d'être des enfants avant que d'être des hommes, que diantre! Accessoirement, comprendre qu'il n'y a pas que les surdoués qui aient le droit de vivre. Et je crois vraiment que Python est très bien pour prendre en compte ça, bien mieux que le regretté Basic de mes premières amours.
Re: Apprendre la programmation en C.
Certes, Eric S. Raymond conseille dans son document How to become a hacker (hacker au sens initial de bidouilleur, pas de pirate), d'apprendre à programmer avec Python...
http://www.catb.org/esr/faqs/hacker-howto.html#skills1
http://www.catb.org/esr/faqs/hacker-howto.html#skills1
Re: Apprendre la programmation en C.
- Dans les vieillerie,:
Pascal était pas mal pour découvrir les joies de la programmation et de l'algorithmique
Bon je reprends mon déhambulateur, j'ai piscine.
Bon courage Stauk
Invité- Invité
Re: Apprendre la programmation en C.
message censuré
Dernière édition par Roger le Dim 17 Déc 2017 - 1:55, édité 1 fois
Invité- Invité
Re: Apprendre la programmation en C.
des bases et plus et des interlocuteurs
doom- Messages : 941
Date d'inscription : 04/08/2012
Age : 60
Localisation : ici et maintenant
Re: Apprendre la programmation en C.
Je ne trouve pas ce que tu dis très convaincant, Roger, mais ça n'en est pas moins intéressant.
Je pense quand même que tu as une grosse tendance à confondre un débutant lambda avec un THQI débutant. Les surdoués ont le droit de vivre; mais il n'y a pas qu'eux...
Je pense quand même que tu as une grosse tendance à confondre un débutant lambda avec un THQI débutant. Les surdoués ont le droit de vivre; mais il n'y a pas qu'eux...
Re: Apprendre la programmation en C.
Roger a écrit:Tu as perdu tout sens des réalités ou alors tu es très très jeune. Un compilateur de 100ko ne tiendrait même pas dans la mémoire vive d'une machine des années 70: UNIX a été conçu sur un PDP-7, dont la mémoire typique était de 9ko. Il y a des implémentations de Forth qui font moins de 1ko. Pour le minimalisme, tu repasseras.Stauk a écrit:Bah écoute, quand on peut écrire un compilateur en 100Ko tout inclus, je dis que c'est minimaliste.Roger a écrit:
Le C n'est pas minimaliste du tout: la dernière norme fait 683 pages !TinyCC n'est pas aux normes et a été conçu à la base (OTCC) pour faire de l'obfuscation de code. Très mauvais exemple. Tu me confortes dans ma position.TinyCC : 859000 lines/second 29.6 Mb/s
Je veux bien le lien vers ta spec de 683 pages concernant le C-99.
Le comportement de ton programme OCAML n'est pas immédiatement transparent pour un néophyte comme moi. Je ne peux pas dire que je sois convaincu de la pertinence du langage par ton exemple. Tu le présentes comme un langage puissant capable d'implémenter un interpréteur en quelques lignes. Très bien, mais en quoi est ce que cette solution est maintenable, et surtout qu'est ce que ton programme fait au juste ? Je ne sais pas. Tu le présentes aussi comme un langage qui pour écrire un programme trivial, a d'abord besoin de simuler une machine virtuelle, ce qui est assez étrange comme manière de faire de la publicité pour un langage. Avec C aussi tu peux écrire des émulateurs. D'ailleurs TinyCC est une base de départ pour un autre projet de l'auteur : QEMU (un émulateur). Je veux bien que tu m'expliques pourquoi il n'a pas choisis OCAML pour écrire QEMU, si tu as des arguments forts la dessus.
Pour le programme C, qui est le thème du fil, je vais prendre le temps de dire ce que j'en pense.
- le programme que tu nous proposes:
- Code:
#include <stdlib.h>
#include <stdio.h>
#define SIZE 10
int main(void) {
int *tab = malloc(SIZE * (sizeof (int)));
int *p, i, s;
p = tab;
i = 0;
s = SIZE;
while (s > 0) {
*p = i;
p++;
i++;
s--;
}
p = tab;
i = 0;
s = SIZE;
while (s > 0) {
printf("%d\n", *p);
p++;
s--;
}
free(tab);
return EXIT_SUCCESS;
}
- Code:
#include <stdio.h>
#define SIZE 10
int main(){
int i;
for(i=0;i<SIZE;i++){
printf("%i\n",i);
}
return 0;
}
Allouer un tableau de 10 éléments sur le tas ne présente pas un grand intérêt.
tu peux faire la même allocation sur la stack avec l'instruction
int tab[SIZE]; // (au lieu du malloc, puis free)
Si on présume que pour une raison ou une autre ton programme illustre un immense tableau potentiellement grand (de 10 éléments pour l'exemple, mais potentiellement beaucoup plus et potentiellement sur saisie utilisateur et non une constante en dur), alors je dois dire que ton choix de rédaction du programme reste particulièrement peu clair.
Un programme équivalent mais bien plus lisible :
- Code:
#include <stdlib.h>
#include <stdio.h>
#define SIZE 10
int main(void) {
int *tab = malloc(SIZE * (sizeof (int)));
int i;
for(i=0;i<SIZE;i++) {
tab[i] = i;
}
for (i=0;i<SIZE;i++) {
printf("%d\n", tab[i]);
}
free(tab);
return EXIT_SUCCESS;
}
Naturellement si tu cherchais à nous convaincre que C permet d'écrire des programmes qui plantent, ou qui sont non-maintenables, ton exemple est bien choisi. Si ton programme OCAML présente le même niveau de qualité, ça ne m'étonne pas que l'ensemble de ton discours soit un peu obscur. Tu dis de temps en temps des choses approximatives (nombre de pages de la spécification du C ? OTCC fait 2000 caractères dans sa version C, 424 octets dans sa version compilée. On est loin des 1ko de forth. J'ai déjà fourni l'url de la page de Bellard, je te laisse fouiller si tu veux corroborer mon propos. )
J'ai l'impression que tu fais une confusion sur la notion de programmation. Ce que j'appelle programmation est une pratique, c'est à dire une activité que tu conduis en vu d'arriver à un résultat. Cette pratique offre plusieurs niveaux de maîtrise, et aussi différents styles pour l'aborder. Par exemple Petitagore parle visiblement de sa PRATIQUE de la programmation. Mais je n'ai aucune idée de quoi toi tu parles. Tu mentionnes OCAML, mais on ne sait pas si tu as vraiment fait des choses avec ni quoi. Le rapport avec le thème du fil semble plus que lointain. Tu mentionnes que tu as programmé en Java, et que ça ne te plait pas. Au final n'oublie pas qu'ici on est pas payé pour faire des choses, on le fait parce qu'il existe une impulsion à les faire. Et J'aimerais trouver des personnes qui partagent cette impulsion, cette envie irrépressible de faire des trucs, même des choses débiles, mais en tout cas des choses CONCRETES.
On dirait que t'obstines à ne fournir des éléments que pour montrer l'étendue de tes capacités. Mais ça me semble inapproprié, car qui veut se rendre compte de tes capacités, s'en rend rapidement compte en te lisant. Ca n'est pas la peine de tenir des propos complètement hors sujet pour les démontrer, je crois que tout ceux qui veulent bien être honnêtes sont déjà convaincus que tu es quelqu'un qui a beaucoup de capacités. Tu ne montres rien qui pousserait à croire que tu es un génie (contrairement à Bellard pour prendre un exemple en lien avec la conversation), mais intelligent, oui c'est vrai, et je dirais que personne n'en doute, même si au fond j'en sais rien. Moi je n'en doute pas.
Personnellement je me sens isolé, et j'ai toujours envie de rencontrer des gens avec qui je pourrais échanger sans ramer des heures. Souvent quand ces personnes existent, ce sont aussi des gens plutôt intelligents. Mais il y a des gens intelligents avec qui je rame, il y en a beaucoup. Je ne sais pas si c'est dû à mes limites, ou mon manque d'empathie sociale. Je ne sais pas si c'est dû à une différence radicale dans l'approche. En tout cas tu m'as pour l'instant surtout convaincu qu'on a pas du tout les mêmes envies dans la vie. Moi j'ai décidé de m'intéresser au C. Il y a un projet derrière, que je réaliserais peut être, ou peut être pas. C peut également être un outil de prototypage, sans doute pas le meilleurs dans de nombreux cas, mais ça reste un outil utilisable quand on le maîtrise bien. Les gens qui maîtrisent le C ont déjà plusieurs fois changé la face du monde, et continuent encore jours après jours. Pour le moment les gens qui maîtrisent OCAML on fait des contributions beaucoup plus modestes, du moins à ma connaissance.
Et je ne dis pas ça pour convaincre qui que ce soit d'apprendre le C en espérant en retirer autre chose qu'une connaissance historique de l'informatique. Car les arguments qui ont été donnés ici en défaveur de ce langage sont très pertinents. Comme ce lien https://www.developpez.com/actu/172666/Quel-avenir-pour-le-langage-C-Un-developpeur-experimente-fait-ses-adieux-au-langage-et-livre-ses-inquietudes-quant-a-son-avenir/ . Mais on est pas ici pour débattre du choix du C en fait, car j'ai passé trois mois à me poser la question à peser le pour et le contre.
Ca me rappelle cette extrait vidéo que j'avais vu d'une vidéo de Feynman sur youtube, ou il explique dans une métaphore, que s'il est en train d'essayer d'ouvrir un coffre fort, il y a toujours des gens qui viennent et lui écrivent : peut être devriez vous essayer la combinaison 345. Et il répond : mais peut être que j'ai déjà essayé la combinaison 345. Ou peut être que le coffre utilise une combinaison à 5 chiffres. Et il ajoute, ne m'écrivez plus de lettres pour me proposer "et si le monde à très petite échelle ...", je lis toutes ces lettres juste pour être sûr, mais il y a beaucoup d'idées que j'ai déjà envisagées, et qui semblent tout simplement ne pas fonctionner. Et je n'ai plus le temps de répondre à chaque lettre, car il y en a trop.
Il est bien possible que le C soit un mauvais choix de vie, mais si je veux le savoir, il va être nécessaire que je CREUSE un peu le sujet. Et je ne vais inviter personne à me suivre dans ce trou là, car il n'y pas grand chose à y gagner pour 99% des gens qui pourraient être tentés. Je souhaites partager quelques éléments de cette aventure, car je me sens extrêmement seul, et ça me fait du bien de poser sur un forum où des gens passent et lisent, même si c'est en diagonal, ça me fourni une illusion d'existence sociale dont j'ai apparemment besoin, même si je sais intellectuellement que c'est probablement une illusion. Et puis il y a toujours cette issue improbable où quelqu'un avec qui je serais capable de dialoguer s'inviterait sur le fil.
Je n'arrive pas à dialoguer avec toi Roger, pour le moment. Tu es intelligent, mais il manque quelque chose d'important pour pouvoir construire un dialogue ensemble. Peut être ce qu'il manque c'est cette envie de réaliser des projets personnels, ou alors ce besoin de les partager ensuite.
Dernière édition par Stauk le Dim 19 Nov 2017 - 19:16, édité 1 fois
Re: Apprendre la programmation en C.
Stauk a écrit:Naturellement si tu cherchais à nous convaincre que C permet d'écrire des programmes qui plantent, ou qui sont non-maintenables, ton exemple est bien choisi.
Je l'avais pas dit, mais je l'avais pensé très fort!
Re: Apprendre la programmation en C.
Stauk a écrit:Et je ne dis pas ça pour convaincre qui que ce soit d'apprendre le C en espérant en retirer autre chose qu'une connaissance historique de l'informatique. Car les arguments qui ont été donnés ici en défaveur de ce langage sont très pertinents. Comme ce lien https://www.developpez.com/actu/172666/Quel-avenir-pour-le-langage-C-Un-developpeur-experimente-fait-ses-adieux-au-langage-et-livre-ses-inquietudes-quant-a-son-avenir/ .
Eric Raymond est une très grosse tête et un gourou de l'informatique, mais par ailleurs il est légèrement frappé (chaque fois que je le lis partant dans son couplet "la liberté du logiciel et la liberté de porter des armes, c'est la même, et tous ceux qui font de l'informatique sans l'avoir compris se feront péter la gueule comme ceux qui jouent avec un pistolet sans avoir compris qu'il est conçu pour tuer"... j'ai une folle envie de me cacher sous une table et d'appeler le GIGN). Cela dit, tout ce qu'il y a dans son article (avez vous noté que le nom de son blog est "Armed and dangerous"? il me fout vraiment les jetons, ce type) me paraît assez juste, notamment la partie "Python dès qu'on peut, C seulement quand on y est obligé, et Go dans un avenir pas forcément très lointain".
Re: Apprendre la programmation en C.
Hello Stauk !
Qu'est-ce que tu souhaite apprendre concrètement ?
Comment fonctionne la machine ? Juste comment programmer ?
Faire du web ? De l’algorithmie ?
En tout cas, j'ai commencé en apprenant le C, et je trouve ça très bien.
D'une façon générale, je trouve ça bien de commencer avec un langage bas niveau, peu importe lequel.
Ca te permet de voir ce que font les langages haut niveau en coulisse et ça te permet de mieux comprendre la machine et ce qu'est réellement un programme.
Ensuite, une fois acquis tout ça, l'apprentissage de la syntaxe d'un nouveau langage n'est pas sorcier.
Le vrai apprentissage, c'est tout les frameworks qui l'entourent.
@Roger: tu travailles dans quoi par curiosité ?
Qu'est-ce que tu souhaite apprendre concrètement ?
Comment fonctionne la machine ? Juste comment programmer ?
Faire du web ? De l’algorithmie ?
En tout cas, j'ai commencé en apprenant le C, et je trouve ça très bien.
D'une façon générale, je trouve ça bien de commencer avec un langage bas niveau, peu importe lequel.
Ca te permet de voir ce que font les langages haut niveau en coulisse et ça te permet de mieux comprendre la machine et ce qu'est réellement un programme.
Ensuite, une fois acquis tout ça, l'apprentissage de la syntaxe d'un nouveau langage n'est pas sorcier.
Le vrai apprentissage, c'est tout les frameworks qui l'entourent.
@Roger: tu travailles dans quoi par curiosité ?
Sarella- Messages : 256
Date d'inscription : 02/06/2016
Age : 36
Re: Apprendre la programmation en C.
Je partage ça ici, si ça intéresse quelqu'un d'en discuter :
http://cba.mit.edu/docs/papers/11.12.Computing.pdf
@Sarella : je veux apprendre à utiliser le C pour réaliser un (ou des) projets de moyenne taille (Durée = 3 mois à 2 ans /homme), maintenables. Maintenable étant ici défini comme les process qui permettent d'optimiser au mieux la gestion de la vie d'un projet réalisé par une ou deux personnes, sur une durée de 2 à 4 ans avec des évolutions régulières nécessaires sur toute la période. Je veux que le temps de gestion des évolutions ne soit pas bouffé par le temps de recherche et correction des bugs. En clair l'idée est d'éviter au maximum la classe des bugs dits "non-reproductibles", et ceci en utilisant le langage C (qui est réputé pour justement avoir la propriété de faciliter l'existence des bugs non-reproductibles). Les projets seront multithreadés.
http://cba.mit.edu/docs/papers/11.12.Computing.pdf
7. Conclusion
I have reviewed the inspiration, implementation, and implications of the ALA model
for computing. It is based on a belief that a fundamental error was made when computer
science diverged from physical science; by basing the foundations of the former
on those of the latter, hardware and software can be aligned at all levels of description.
I’ve argued that this is not just possible, it is preferable to address many of the
issues in scaling information technologies. Interconnect bottlenecks, challenges in
multicore compilation, quiescent power budgets, and diverging chip design costs are
all symptoms of trying to compute in a world that differs from the one that we actually
live in. These problems are simplified by explicitly recognizing time, space, state, and
logic as coupled properties of a medium in which computing happens
@Sarella : je veux apprendre à utiliser le C pour réaliser un (ou des) projets de moyenne taille (Durée = 3 mois à 2 ans /homme), maintenables. Maintenable étant ici défini comme les process qui permettent d'optimiser au mieux la gestion de la vie d'un projet réalisé par une ou deux personnes, sur une durée de 2 à 4 ans avec des évolutions régulières nécessaires sur toute la période. Je veux que le temps de gestion des évolutions ne soit pas bouffé par le temps de recherche et correction des bugs. En clair l'idée est d'éviter au maximum la classe des bugs dits "non-reproductibles", et ceci en utilisant le langage C (qui est réputé pour justement avoir la propriété de faciliter l'existence des bugs non-reproductibles). Les projets seront multithreadés.
Dernière édition par Stauk le Dim 19 Nov 2017 - 20:38, édité 1 fois
Re: Apprendre la programmation en C.
message censuré
Dernière édition par Roger le Dim 17 Déc 2017 - 1:56, édité 1 fois
Invité- Invité
Re: Apprendre la programmation en C.
Si ça continue, les fils sur la programmation vont donner autant de boulot aux modos que ceux sur la religion...
Re: Apprendre la programmation en C.
Roger a écrit:
Bellard fait ce qui lui plaît. C'est son problème. Tu l'as lu le code de OTCC ? Tu l'as vraiment lu ? Tu crois vraiment que tu peux apprendre à programmer avec ça ? Dis-moi que c'est une blague !
Je l'ai regardé, ce n'est pas vraiment ma tasse de thé. Mais j'ai toujours eu du mal avec les programmes écrits par d'autres.
ou Bellard dont les hauts faits consistent à écrire des programmes illisibles.
Il est plus connu pour son record algorithmique du calcul des décimales de Pi. Bon il est connu aussi pour beaucoup d'autres hauts faits, mais à la rigueur si ça t'intéressait tu le saurais déjà. Je le citais juste pour montrer que comparé à un mec (vraiment) intelligent, la différence entre la plupart des gens qui se disputent sur ZC est négligeable. On est pas des génies, contrairement à d'autres qui eux le sont. Enfin tu le savais déjà, je sais pas pourquoi je te l'explique comme si t'étais neuneu.
https://bellard.org/pi/pi2700e9/announce.html
Bellard a écrit:
December 31st, 2009
I am pleased to announce a new world record for the computation of the digits of Pi. The following number of digits were computed:
2242301460000 hexadecimal digits (base 16)
2699999990000 decimal digits (base 10)
The base 10 result needs about 1137 GB(1) of storage. Parts of the result are available here.
Most of the computation was carried out on a single desktop computer costing less than 2000 euros. The previous records since 1995 were done using multi-million euro supercomputers.
Je ne te prends pas pour un con. J'imagine que tu avais conscience que je m'apprêtais à te mettre sur ma liste des ignorés. C'est pas que tu ne dises rien d'intéressant, c'est que ta manière de dire les choses rend trop coûteux le fait de m'instruire. Je préfère apprendre le C que de m’intéresser à ton point de vue philosophique sur des questions dont tu ne m'as pas convaincu que tu les maîtrises. D'ailleurs si tu les maîtrises, ou si tu les maîtrisais, ça ne ferait pas nécessairement de toi une bonne source d'information pour autant. Etant donné le coût induit par ta manière de formuler tes exclamations.Roger a écrit:
Prend-moi pour un con, j'aime bien
J'essayais juste de rester poli et in the charte. Je dirais bien que tu dépasses les bornes avec ce genres de phrases, mais en fait on s'en fout un peu, au fond. Toi moi, et tous les autres qui nous lisent.
Voilà, tu continues à reluquer mon doigt. Le trouves-tu trop grand, trop gros ou trop vigoureux à ton goût.
Ce n'est pas mon ambition, mais si je me sentais capable de travailler sur des programmes aussi critiques, et qu'on m'offrait ce genres d'opportunités, je le prendrais comme un compliment. Ca ne sera pas le cas. J'ai vraiment envie de faire des petites choses, qui impliquent moins de hiérarchies que de travailler sur ces genres de projets.
Avec un peu de chance, tu feras exploser une fusée ou tu tueras quelques cancéreux avec tes programmes pourris.
C'est impressionnant qu'on t'ait laissé la possibilité d'observer de telles choses, étant donnés les aspects un peu rugueux de ta communication. Moi j'ai pas vu. Par contre j'ai lu dans des journaux qu'en effet ça se passe comme ça, sauf peut être sur la raison profonde de la cause du truc. Enfin même si une analyse des projets ratés aurait sans doute sa place sur ce fil, je vais comme je l'ai déjà formulé plusieurs fois, te mettre sur la liste d'ignorés. Et partant, je ne répondrais plus de façon aussi complète que j'ai pu le faire ces derniers temps, à tes propos. Débattre avec toi ne m'intéresse pas beaucoup, et lire ta frustration pas tellement d'avantage : j'ai la mienne, qui est au moins comparable je pense, et aussi celle de pleins d'autres gens, qui sont quand même vachement plus agréables à lire ou autre.
j'ai vu des projets à plusieurs centaines de millions d'euros - oui, des centaines de millions d'euros ! - se vautrer complètement du fait d'incompétents qui se prennent pour des W1z@rdZ.
Bon ben c'est parfait, je n'aurais donc pas à te faire un dessin.Roger a écrit:
Je sais ce qui arrivera
Re: Apprendre la programmation en C.
message censuré
Dernière édition par Roger le Dim 17 Déc 2017 - 1:56, édité 1 fois
Invité- Invité
Re: Apprendre la programmation en C.
.
Dernière édition par ortolan le Ven 22 Déc 2017 - 19:46, édité 1 fois
ortolan- Messages : 13579
Date d'inscription : 31/07/2016
Localisation : 404 Not Found
Re: Apprendre la programmation en C.
@Roger : je corrige un peu l'inexactitude de ton propos (comme souvent on ne peut pas te faire confiance, et c'est dommage).
Voici le code de OTCC :
https://bellard.org/otcc/otccn.c
Je te propose de quitter ce fil, ou d'essayer de creuser un peu les sujets avant de dire n'importe quoi, merci d'avance.
Voici le code de OTCC :
https://bellard.org/otcc/otccn.c
- Code:
/*
Obfuscated Tiny C Compiler
Copyright (C) 2001-2003 Fabrice Bellard
This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.
Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely, subject to the following restrictions:
1. The origin of this software must not be misrepresented; you must not
claim that you wrote the original software. If you use this software
in a product, an acknowledgment in the product and its documentation
*is* required.
2. Altered source versions must be plainly marked as such, and must not be
misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.
*/
#ifndef TINY
#include <stdarg.h>
#endif
#include <stdio.h>
/* vars: value of variables
loc : local variable index
glo : global variable index
ind : output code ptr
rsym: return symbol
prog: output code
dstk: define stack
dptr, dch: macro state
*/
int tok, tokc, tokl, ch, vars, rsym, prog, ind, loc, glo, file, sym_stk, dstk, dptr, dch, last_id;
#define ALLOC_SIZE 99999
/* depends on the init string */
#define TOK_STR_SIZE 48
#define TOK_IDENT 0x100
#define TOK_INT 0x100
#define TOK_IF 0x120
#define TOK_ELSE 0x138
#define TOK_WHILE 0x160
#define TOK_BREAK 0x190
#define TOK_RETURN 0x1c0
#define TOK_FOR 0x1f8
#define TOK_DEFINE 0x218
#define TOK_MAIN 0x250
#define TOK_DUMMY 1
#define TOK_NUM 2
#define LOCAL 0x200
#define SYM_FORWARD 0
#define SYM_DEFINE 1
/* tokens in string heap */
#define TAG_TOK ' '
#define TAG_MACRO 2
pdef(t)
{
*(char *)dstk++ = t;
}
inp()
{
if (dptr) {
ch = *(char *)dptr++;
if (ch == TAG_MACRO) {
dptr = 0;
ch = dch;
}
} else
ch = fgetc(file);
/* printf("ch=%c 0x%x\n", ch, ch); */
}
isid()
{
return isalnum(ch) | ch == '_';
}
/* read a character constant */
getq()
{
if (ch == '\\') {
inp();
if (ch == 'n')
ch = '\n';
}
}
next()
{
int t, l, a;
while (isspace(ch) | ch == '#') {
if (ch == '#') {
inp();
next();
if (tok == TOK_DEFINE) {
next();
pdef(TAG_TOK); /* fill last ident tag */
*(int *)tok = SYM_DEFINE;
*(int *)(tok + 4) = dstk; /* define stack */
}
/* well we always save the values ! */
while (ch != '\n') {
pdef(ch);
inp();
}
pdef(ch);
pdef(TAG_MACRO);
}
inp();
}
tokl = 0;
tok = ch;
/* encode identifiers & numbers */
if (isid()) {
pdef(TAG_TOK);
last_id = dstk;
while (isid()) {
pdef(ch);
inp();
}
if (isdigit(tok)) {
tokc = strtol(last_id, 0, 0);
tok = TOK_NUM;
} else {
*(char *)dstk = TAG_TOK; /* no need to mark end of string (we
suppose data is initied to zero */
tok = strstr(sym_stk, last_id - 1) - sym_stk;
*(char *)dstk = 0; /* mark real end of ident for dlsym() */
tok = tok * 8 + TOK_IDENT;
if (tok > TOK_DEFINE) {
tok = vars + tok;
/* printf("tok=%s %x\n", last_id, tok); */
/* define handling */
if (*(int *)tok == SYM_DEFINE) {
dptr = *(int *)(tok + 4);
dch = ch;
inp();
next();
}
}
}
} else {
inp();
if (tok == '\'') {
tok = TOK_NUM;
getq();
tokc = ch;
inp();
inp();
} else if (tok == '/' & ch == '*') {
inp();
while (ch) {
while (ch != '*')
inp();
inp();
if (ch == '/')
ch = 0;
}
inp();
next();
} else
{
t = "++#m--%am*@R<^1c/@%[_[H3c%@%[_[H3c+@.B#d-@%:_^BKd<<Z/03e>>`/03e<=0f>=/f<@.f>@1f==&g!=\'g&&k||#l&@.BCh^@.BSi|@.B+j~@/%Yd!@&d*@b";
while (l = *(char *)t++) {
a = *(char *)t++;
tokc = 0;
while ((tokl = *(char *)t++ - 'b') < 0)
tokc = tokc * 64 + tokl + 64;
if (l == tok & (a == ch | a == '@')) {
#if 0
printf("%c%c -> tokl=%d tokc=0x%x\n",
l, a, tokl, tokc);
#endif
if (a == ch) {
inp();
tok = TOK_DUMMY; /* dummy token for double tokens */
}
break;
}
}
}
}
#if 0
{
int p;
printf("tok=0x%x ", tok);
if (tok >= TOK_IDENT) {
printf("'");
if (tok > TOK_DEFINE)
p = sym_stk + 1 + (tok - vars - TOK_IDENT) / 8;
else
p = sym_stk + 1 + (tok - TOK_IDENT) / 8;
while (*(char *)p != TAG_TOK && *(char *)p)
printf("%c", *(char *)p++);
printf("'\n");
} else if (tok == TOK_NUM) {
printf("%d\n", tokc);
} else {
printf("'%c'\n", tok);
}
}
#endif
}
#ifdef TINY
#define skip(c) next()
#else
void error(char *fmt,...)
{
va_list ap;
va_start(ap, fmt);
fprintf(stderr, "%d: ", ftell((FILE *)file));
vfprintf(stderr, fmt, ap);
fprintf(stderr, "\n");
exit(1);
va_end(ap);
}
void skip(c)
{
if (tok != c) {
error("'%c' expected", c);
}
next();
}
#endif
o(n)
{
/* cannot use unsigned, so we must do a hack */
while (n && n != -1) {
*(char *)ind++ = n;
n = n >> 8;
}
}
/* output a symbol and patch all calls to it */
gsym(t)
{
int n;
while (t) {
n = *(int *)t; /* next value */
*(int *)t = ind - t - 4;
t = n;
}
}
/* psym is used to put an instruction with a data field which is a
reference to a symbol. It is in fact the same as oad ! */
#define psym oad
/* instruction + address */
oad(n, t)
{
o(n);
*(int *)ind = t;
t = ind;
ind = ind + 4;
return t;
}
/* load immediate value */
li(t)
{
oad(0xb8, t); /* mov $xx, %eax */
}
gjmp(t)
{
return psym(0xe9, t);
}
/* l = 0: je, l == 1: jne */
gtst(l, t)
{
o(0x0fc085); /* test %eax, %eax, je/jne xxx */
return psym(0x84 + l, t);
}
gcmp(t)
{
o(0xc139); /* cmp %eax,%ecx */
li(0);
o(0x0f); /* setxx %al */
o(t + 0x90);
o(0xc0);
}
gmov(l, t)
{
o(l + 0x83);
oad((t < LOCAL) << 7 | 5, t);
}
/* l is one if '=' parsing wanted (quick hack) */
unary(l)
{
int n, t, a, c;
n = 1; /* type of expression 0 = forward, 1 = value, other =
lvalue */
if (tok == '"') {
li(glo);
while (ch != '"') {
getq();
*(char *)glo++ = ch;
inp();
}
*(char *)glo = 0;
glo = glo + 4 & -4; /* align heap */
inp();
next();
} else {
c = tokl;
a = tokc;
t = tok;
next();
if (t == TOK_NUM) {
li(a);
} else if (c == 2) {
/* -, +, !, ~ */
unary(0);
oad(0xb9, 0); /* movl $0, %ecx */
if (t == '!')
gcmp(a);
else
o(a);
} else if (t == '(') {
expr();
skip(')');
} else if (t == '*') {
/* parse cast */
skip('(');
t = tok; /* get type */
next(); /* skip int/char/void */
next(); /* skip '*' or '(' */
if (tok == '*') {
/* function type */
skip('*');
skip(')');
skip('(');
skip(')');
t = 0;
}
skip(')');
unary(0);
if (tok == '=') {
next();
o(0x50); /* push %eax */
expr();
o(0x59); /* pop %ecx */
o(0x0188 + (t == TOK_INT)); /* movl %eax/%al, (%ecx) */
} else if (t) {
if (t == TOK_INT)
o(0x8b); /* mov (%eax), %eax */
else
o(0xbe0f); /* movsbl (%eax), %eax */
ind++; /* add zero in code */
}
} else if (t == '&') {
gmov(10, *(int *)tok); /* leal EA, %eax */
next();
} else {
n = *(int *)t;
/* forward reference: try dlsym */
if (!n)
n = dlsym(0, last_id);
if (tok == '=' & l) {
/* assignment */
next();
expr();
gmov(6, n); /* mov %eax, EA */
} else if (tok != '(') {
/* variable */
gmov(8, n); /* mov EA, %eax */
if (tokl == 11) {
gmov(0, n);
o(tokc);
next();
}
}
}
}
/* function call */
if (tok == '(') {
if (n == 1)
o(0x50); /* push %eax */
/* push args and invert order */
a = oad(0xec81, 0); /* sub $xxx, %esp */
next();
l = 0;
while(tok != ')') {
expr();
oad(0x248489, l); /* movl %eax, xxx(%esp) */
if (tok == ',')
next();
l = l + 4;
}
*(int *)a = l;
next();
if (!n) {
/* forward reference */
t = t + 4;
*(int *)t = psym(0xe8, *(int *)t);
} else if (n == 1) {
oad(0x2494ff, l); /* call *xxx(%esp) */
l = l + 4;
} else {
oad(0xe8, n - ind - 5); /* call xxx */
}
if (l)
oad(0xc481, l); /* add $xxx, %esp */
}
}
sum(l)
{
int t, n, a;
if (l-- == 1)
unary(1);
else {
sum(l);
a = 0;
while (l == tokl) {
n = tok;
t = tokc;
next();
if (l > {
a = gtst(t, a); /* && and || output code generation */
sum(l);
} else {
o(0x50); /* push %eax */
sum(l);
o(0x59); /* pop %ecx */
if (l == 4 | l == 5) {
gcmp(t);
} else {
o(t);
if (n == '%')
o(0x92); /* xchg %edx, %eax */
}
}
}
/* && and || output code generation */
if (a && l > {
a = gtst(t, a);
li(t ^ 1);
gjmp(5); /* jmp $ + 5 */
gsym(a);
li(t);
}
}
}
expr()
{
sum(11);
}
test_expr()
{
expr();
return gtst(0, 0);
}
block(l)
{
int a, n, t;
if (tok == TOK_IF) {
next();
skip('(');
a = test_expr();
skip(')');
block(l);
if (tok == TOK_ELSE) {
next();
n = gjmp(0); /* jmp */
gsym(a);
block(l);
gsym(n); /* patch else jmp */
} else {
gsym(a); /* patch if test */
}
} else if (tok == TOK_WHILE | tok == TOK_FOR) {
t = tok;
next();
skip('(');
if (t == TOK_WHILE) {
n = ind;
a = test_expr();
} else {
if (tok != ';')
expr();
skip(';');
n = ind;
a = 0;
if (tok != ';')
a = test_expr();
skip(';');
if (tok != ')') {
t = gjmp(0);
expr();
gjmp(n - ind - 5);
gsym(t);
n = t + 4;
}
}
skip(')');
block(&a);
gjmp(n - ind - 5); /* jmp */
gsym(a);
} else if (tok == '{') {
next();
/* declarations */
decl(1);
while(tok != '}')
block(l);
next();
} else {
if (tok == TOK_RETURN) {
next();
if (tok != ';')
expr();
rsym = gjmp(rsym); /* jmp */
} else if (tok == TOK_BREAK) {
next();
*(int *)l = gjmp(*(int *)l);
} else if (tok != ';')
expr();
skip(';');
}
}
/* 'l' is true if local declarations */
decl(l)
{
int a;
while (tok == TOK_INT | tok != -1 & !l) {
if (tok == TOK_INT) {
next();
while (tok != ';') {
if (l) {
loc = loc + 4;
*(int *)tok = -loc;
} else {
*(int *)tok = glo;
glo = glo + 4;
}
next();
if (tok == ',')
next();
}
skip(';');
} else {
/* patch forward references (XXX: do not work for function
pointers) */
gsym(*(int *)(tok + 4));
/* put function address */
*(int *)tok = ind;
next();
skip('(');
a = 8;
while (tok != ')') {
/* read param name and compute offset */
*(int *)tok = a;
a = a + 4;
next();
if (tok == ',')
next();
}
next(); /* skip ')' */
rsym = loc = 0;
o(0xe58955); /* push %ebp, mov %esp, %ebp */
a = oad(0xec81, 0); /* sub $xxx, %esp */
block(0);
gsym(rsym);
o(0xc3c9); /* leave, ret */
*(int *)a = loc; /* save local variables */
}
}
}
main(n, t)
{
file = stdin;
if (n-- > 1) {
t = t + 4;
file = fopen(*(int *)t, "r");
}
dstk = strcpy(sym_stk = calloc(1, ALLOC_SIZE),
" int if else while break return for define main ") + TOK_STR_SIZE;
glo = calloc(1, ALLOC_SIZE);
ind = prog = calloc(1, ALLOC_SIZE);
vars = calloc(1, ALLOC_SIZE);
inp();
next();
decl(0);
#ifdef TEST
{
FILE *f;
f = fopen(*(char **)(t + 4), "w");
fwrite((void *)prog, 1, ind - prog, f);
fclose(f);
return 0;
}
#else
return (*(int (*)())*(int *)(vars + TOK_MAIN)) (n, t);
#endif
}
Je te propose de quitter ce fil, ou d'essayer de creuser un peu les sujets avant de dire n'importe quoi, merci d'avance.
Re: Apprendre la programmation en C.
message censuré
Dernière édition par Roger le Dim 17 Déc 2017 - 1:56, édité 1 fois
Invité- Invité
Re: Apprendre la programmation en C.
Stauk a écrit:@Sarella : je veux apprendre à utiliser le C pour réaliser un (ou des) projets de moyenne taille (Durée = 3 mois à 2 ans /homme), maintenables. Maintenable étant ici défini comme les process qui permettent d'optimiser au mieux la gestion de la vie d'un projet réalisé par une ou deux personnes, sur une durée de 2 à 4 ans avec des évolutions régulières nécessaires sur toute la période. Je veux que le temps de gestion des évolutions ne soit pas bouffé par le temps de recherche et correction des bugs. En clair l'idée est d'éviter au maximum la classe des bugs dits "non-reproductibles", et ceci en utilisant le langage C (qui est réputé pour justement avoir la propriété de faciliter l'existence des bugs non-reproductibles). Les projets seront multithreadés.
C'est des projets web ?
Est-ce que tes projets ont besoin de perf ?
Je dirais que si tu peux, prends des langages plus haut niveau style Golang (très bien pour le multithread d'ailleurs).
C'est plus facile/rapide à coder et ça s'occupe de plein de truc (la gestion de la mémoire par exemple).
Les bugs non-reproductibles, ce sera plutôt l'architecture de ton appli qui les causera. (en tout cas si tu fais un projet type web)
Sarella- Messages : 256
Date d'inscription : 02/06/2016
Age : 36
Re: Apprendre la programmation en C.
Petitagore a écrit:Si ça continue, les fils sur la programmation vont donner autant de boulot aux modos que ceux sur la religion...
Y'a toujours un codeur-hippy qui vient convertir la plèbe ignare à son langage. :/
S'en est presque un running gag...
Sarella- Messages : 256
Date d'inscription : 02/06/2016
Age : 36
Re: Apprendre la programmation en C.
Sarella a écrit:
Est-ce que tes projets ont besoin de perf ?
Oui. Certains. Mais ce n'est pas l'unique raison du choix de C. L'autre raison c'est d'essayer de réaliser un projet en C, pour avoir du recul sur comment réaliser un projet en C.Il n'y a pas de web, mais je serais satisfait d'avoir le choix de pouvoir exécuter certains projets via une page, même si ça ne fait pas partie des priorités dans l'immédiat. Une autre raison du choix de C, c'est que je dépends moins des concepts de hauts niveaux, et donc je peux envisager de créer les miens, ou en tout cas essayer de le faire dans les limites de ce que je propose ce langage. Besoin de liberté.
Bref c'est à la fois un choix pratique, mais c'est aussi un choix personnel, de parcours. Il semblerait que C soit sur le chemin que je souhaites emprunter en ce moment.
Re: Apprendre la programmation en C.
Passer par le C ne peut que faire du bien à mon avis. ^^
Tu vas t'amuser et t'arracher les cheveux!
Tu vas t'amuser et t'arracher les cheveux!
Sarella- Messages : 256
Date d'inscription : 02/06/2016
Age : 36
Re: Apprendre la programmation en C.
Pour ce qui est de la spécification du C, il parait que la norme de 99 est deprecated, et qu'il faut se référer à la norme de 2011. Elle fait fait 701 page. Donc un point pour Roger concernant le nombre de pages. Ce qui ne lui donne pas raison sur le reste.
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
Dernière édition par Stauk le Lun 20 Nov 2017 - 7:13, édité 1 fois
Re: Apprendre la programmation en C.
Je me rends compte que tout ça fait beaucoup de blahblah, que j'écris au fil de ce qui me vient. Ca me permet de brainstormer, mais c'est assez indigeste pour le lecteur éventuel. Z'êtes prévenus ...
- Spoiler:
Mon objectif actuel est d'être capable d'écrire des prototypes qui tournent à la fois sous windows et linux, et qui donnent accès à la souris au clavier et à l'écran. Il existe une bibliothèque cross-compatible qui fourni tout ça, et qui est bien maintenue. J'ai fait un test sous linux, et de cross-compilation vérifiée ensuite avec Wine, et ça semble fonctionner. La librairie s'appelle SDL2.
Le code que j'ai cross compilé (linux/windows) avec succès est le suivant :- Code:
// http://gigi.nullneuron.net/gigilabs/loading-images-in-sdl2-with-sdl_image/
// gcc file -lSDL2
// surface vs texture : https://stackoverflow.com/questions/12506979/what-is-the-point-of-an-sdl2-texture
#include "SDL2/SDL.h"
int main(int argc, char ** argv)
{
char quit = 0;
SDL_Event event;
SDL_Init(SDL_INIT_VIDEO);
SDL_Window * window = SDL_CreateWindow("SDL2 Displaying Image",
SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, 640, 480, 0);
SDL_Renderer * renderer = SDL_CreateRenderer(window, -1, 0);
SDL_Surface * image = SDL_LoadBMP("image.bmp");
SDL_Texture * texture = SDL_CreateTextureFromSurface(renderer, image);
while (!quit)
{
SDL_WaitEvent(&event);
switch (event.type)
{
case SDL_QUIT:
quit = 1;
break;
}
SDL_Rect dstrect = { 5, 5, 320, 240 };
SDL_Rect srcrect = { 320/2, 240/2, 320/20+100, 240/2 + 75 };
SDL_Rect dst2rect = { 320, 240, 320+100, 240+75 };
SDL_RenderCopy(renderer, texture, NULL, NULL);
SDL_RenderCopy(renderer, texture, NULL, &dstrect);
SDL_RenderCopy(renderer, texture, &srcrect, &dst2rect);
SDL_RenderPresent(renderer);
}
SDL_DestroyTexture(texture);
SDL_FreeSurface(image);
SDL_DestroyRenderer(renderer);
SDL_DestroyWindow(window);
SDL_Quit();
return 0;
}
Pour s’exécuter le code a besoin de la librairie SDL2, et aussi de l'image "image.bmp" dans le chemin courant.
J'ai essayé aussi de me faire une idée un peu plus précise de ce qu'est le C. On note deux parties complémentaires de ce langage : le langage de base, et le langage Macro. Le but du langage Macro qui est appliqué avant la compilation, est d'enrichir le langage C, pour aider à en dépasser les limites et l'adapter au besoin du moment.
Le langage C de lui même permet d'écrire un programme en assembleur "portable", et de ne pas se perdre en optimisations que le compilateur est capable d'effectuer de lui même. Il vient donc compléter les outils d'assemblage classique, et offre une forme de portabilité.
Le langage C est également un langage de Haut Niveau (dans la mesure où il s'inscrit dans une perspective de supplantation de l'usage des langages assembleurs).
Cette double casquette Assembleur portable/Langage de haut niveau en fait aujourd'hui en 2017 une solution un peu hybride, qui ne fait bien ni l'un ni l'autre. C'est un très mauvais langage de haut niveau, et c'est aussi un assembleur portable assez mal adapté aux réalités de notre époque (2017). Il existe un langage qui est souvent cité comme étant également un assembleur portable, le langage LLVM IR
https://idea.popcount.org/2013-07-24-ir-is-better-than-assembly/
Il existe d'autres langages de hauts niveaux qui ont déjà étés cités.
Le type de programmation que je me propose d'effectuer est "proche de la machine", qu'on appelle aussi "programmation système", c'est à dire un type de programmation où il n'existe que la mémoire et les instructions qu'on peut lui appliquer, mais pas de bibliothèques. Il est souvent nécessaire d'inscrire un programme dans un environnement toutefois, en général il va s'agir des éléments suivants :
- console de sortie
- clavier, souris
- écran
- réseaux (souvent socket [tcp/udp], éventuellement HTTP et WEBRTC / websocket si on est sous navigateur)
- son [je fais l'impasse la dessus pour le moment, mais ça peut être intéressant d'y avoir accès]
Mes programmes sont présumés être donc à la fois bindé avec ces éléments matériels, de la façon la plus portable possible, afin de fournir des feeds-backs sur le programme executé, et à la fois indépendant de ces éléments, et uniquement dépendant de la mémoire disponible et des transformations qu'on peut lui appliquer. Le coté "haut niveau" du langage C est largement suffisant pour effectuer le binding avec une librairie qui est aujourd'hui bien supportée sous linux, mac et windows (sdl2). A priori la programmation bas niveau serait également effectuée en C. L'avantage de programmer en C, est d'abord la facilité pour effectuer le binding. Et ensuite la portabilité.
Mais comme on l'a vu la question de savoir si le C est la bonne façon en 2017 d'écrire du code machine indépendant de toute librairie externe qui soit portable, n'est pas encore 100% clair dans mon esprit. Ce que je reproche à LLVM-IR, c'est d'être mastok, et trop complexe à mon goût. Honnêtement je n'ai pas envie de me taper des milliers de pages d'un syntaxe obscure, pour pouvoir écrire un programme qui prépare la chaîne de caractère "maman fait du chocolat". Bref LLVM-IR ne m'attire pas beaucoup, même s'il est un excellent représentant de la classe des langages portables de bas niveau raisonnablement cross platforme.
Un programme (bas niveau) est à la fois un modèle conceptuel, mais aussi souvent est directement liés aux capacités de la machine. De nos jours les aspects multithread et synchronization mais aussi les instructions SIMD (single instruction multiple data) doivent être prise en compte. Les SIMD sont disponibles à la fois sur du hardware spécialisé (les cartes graphiques pour nos ordinateurs de nos maisons, qu'on peut programmer via les Shaders, essentiellement dans un langage simili-C), mais aussi sur les nos processeurs habituels par exemple avec l'extension AVX2 (et toutes celles qui ont précédé)
https://en.wikipedia.org/wiki/AVX-512
Le pc sur mon bureau est capable d’effectuer des instructions sur des opérandes de 512 bits, et le votre également, si vous avez un processeur récent.
Le programme bas niveau a donc deux régimes distincts, un régime "lent" où les performances ne sont pas vraiment critiques et on peut se concentrer sur d'autres aspects, et un régime "rapide" ou le besoin de performance sans être nécessairement tout à fait critique est tout de même présent. Le problème du régime rapide c'est qu'on est contraint par la machine, et le bon langage va dépendre du hardware qu'on a sous la main.
J'ai parlé plus haut des langage assembleur portables, il existe un autre langage assembleur portable, destiné à nos cartes graphiques : SPIR-V.
SPIR-V est un langage assembleur crossplatforme qui est conçu pour unifier la programmation des cartes graphiques. C'est un langage bas niveau qui est assez compliqué, du fait qu'il est destiné à s'adapter à différents hardware. Le regarder dans le détail serait malheureusement un peu trop time-consuming pour moi.
Sur nos pc de bureau, le langage SPIR-V est généralement déployé à travers les Shaders, par exemple via une API vulkan http://www.duskborn.com/a-simple-vulkan-compute-example/
https://github.com/KhronosGroup/SPIRV-Tools
Spécification de SPIR-V
https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.pdf
Si je comprends bien l'idée, c'est d'essayer d'avoir une idées à priori des capacités que peuvent avoir nos super-calculateurs (enfin cartes graphiques donc), et de disposer d'un langage où chaque programme est capable de spécifier ses attentes. Si le hardware ne supporte pas les attentes du programmes il répondra simplement "désolé je ne sais pas faire", et il faudra proposer un autre programme. Pour revenir à ma métaphore "slow"/"fast", un slow programme SPIR-V essaiera donc de faire beaucoup avec les instructions supportées par tous les vendeurs, tandis qu'un "FAST" aura à cœur de soit cibler un niveau de capacité particulier, soit de fournir plusieurs implémentations.
On remarque donc une certaines forme de continuum du "slow but compatible" vers "fast but very specific". Le langage C n'échappe pas non plus à ces aspects. Le langage C est naturellement "slow but compatible", mais offre des possibilités d'extensions vers "fast but very specific". Toutefois autant SPIR-V intègre la détection des capacités du hardware de façon native dans le standard, autant C intègre juste un langage représentatif des capacités des machines de l'époque, et c'est au programmeur et à ses librairies de se démerder pour détecter le hardware.
Une fois le hardware détecté, le C dispose de plusieurs options pour utiliser les capacités. Il y a des directives qu'on peut passer en ligne de commande au compilateur, et il y a des intrinsics qu'on peut utiliser pour lui fournir des indices de ce qu'on aimerait faire. Par ailleurs on peut également lui refiler du code assembleur soit directement intégré au code C, soit sous la forme d'un objet assemblé dans un format compatible avec les règles d'appel du langage C.
Un des avantages du langage C, c'est cette inter-compatibilité transparente avec le langage assembleur.
Re: Apprendre la programmation en C.
En blablatant ici, et en lisant vos réponses, je me rend compte que le choix de C n'est pas encore 100% acquis. Ce que j'ai déjà choisis c'est de rester compatible avec la philosophie de C, et de l'utiliser comme langage d'assemblage. Mais ce n'est pas le C qui m'intéresse à cet effet, mais uniquement les outils disponibles autour. Mon choix est de faire de la programmation bas niveau, en utilisant C pour faire l'interface avec des librairies génériques d'accès au contexte (souris, clavier, écran).
Je pense que ça serait bien que je donne un exemple de programme concret. Je ne vais pas parler de mes projets spécifiques mais on peut considérer un cas d'utilisateur qui couvre une bonne partie de mes besoins. Le jeu de la vie, avec possibilité pour l'utilisateur d'interagir avec la grille. On trouve des version qui s’exécutent sous vos navigateur, et qui sont écrit donc pour le shader de votre carte graphique. Le programme (c-like) est compilé à la volée par votre processeur, puis envoyé à la carte graphique (qui recompile le byte-code de haut niveau vers son langage spécifique propriétaire, à la volée aussi).
Voici un lien vers un programme web de type "jeux de la vie" executé via les shaders :
http://nullprogram.com/webgl-game-of-life/
voici un autre lien vers un programme similaire sur navigateur également. Vous avez besoin d'un navigateur compatible webgl, c'est à dire un smartphone moderne, ou un pc équipé d'une carte graphique non antédilluvienne.
https://xpl.github.io/expression/
Je pense que ça serait bien que je donne un exemple de programme concret. Je ne vais pas parler de mes projets spécifiques mais on peut considérer un cas d'utilisateur qui couvre une bonne partie de mes besoins. Le jeu de la vie, avec possibilité pour l'utilisateur d'interagir avec la grille. On trouve des version qui s’exécutent sous vos navigateur, et qui sont écrit donc pour le shader de votre carte graphique. Le programme (c-like) est compilé à la volée par votre processeur, puis envoyé à la carte graphique (qui recompile le byte-code de haut niveau vers son langage spécifique propriétaire, à la volée aussi).
Voici un lien vers un programme web de type "jeux de la vie" executé via les shaders :
http://nullprogram.com/webgl-game-of-life/
voici un autre lien vers un programme similaire sur navigateur également. Vous avez besoin d'un navigateur compatible webgl, c'est à dire un smartphone moderne, ou un pc équipé d'une carte graphique non antédilluvienne.
https://xpl.github.io/expression/
Re: Apprendre la programmation en C.
J'ai fait un petit test pour voir un peu comment un programme en assembleur se crosscompile pour linux / windows.
Alors déjà il faut modifier comment sont récupérés les arguments, car les deux environnements n'utilisent pas les même conventions. Pratique. Ensuite gcc / mingw n'utilisent pas les même noms pour un même programme assembleur, lors de l'export du nom. sous windows un _ est ajouté au nom exporté, mais pas sous linux.
donc le même fichier .S compilé avec la même commande par mingw ou gcc n'exporte pas le même nom. Par ailleurs le programme assembleur n'est à priori pas compatible avec à la fois un appel généré par un programme compilé avec gcc ET un programme compilé avec mingw.
Alors déjà il faut modifier comment sont récupérés les arguments, car les deux environnements n'utilisent pas les même conventions. Pratique. Ensuite gcc / mingw n'utilisent pas les même noms pour un même programme assembleur, lors de l'export du nom. sous windows un _ est ajouté au nom exporté, mais pas sous linux.
donc le même fichier .S compilé avec la même commande par mingw ou gcc n'exporte pas le même nom. Par ailleurs le programme assembleur n'est à priori pas compatible avec à la fois un appel généré par un programme compilé avec gcc ET un programme compilé avec mingw.
Re: Apprendre la programmation en C.
Un autre truc sur lequel Roger m'a fait réfléchir, c'est le manque de recul que j'ai sur l'époque où l'informatique était simple. Par exemple je n'ai jamais essayé de m'intéresser aux cpu 8 bits. Alors que je me dis que ça ne doit pas être si compliqué. Les abstractions qu'on utilise aujourd'hui sont héritées de cette époque.
https://en.wikipedia.org/wiki/8-bit
https://eater.net/8bit/
https://hackaday.com/2016/02/24/8-bit-computer-made-solely-from-nand-gates/
https://en.wikipedia.org/wiki/8-bit
https://eater.net/8bit/
https://www.researchgate.net/profile/Luis_Carlos_Herrero-De_Lucas/publication/267766934_A_very_simple_8-bit_RISC_processor_for_FPGA/links/56f17c0108ae1cb29a3d116d/A-very-simple-8-bit-RISC-processor-for-FPGA.pdf
This article presents the “RISCuva1” processor, a
very simple 8-bit RISC processor for FPGA. Its most
important feature is that this processor is very simple. Its
Verilog code has about 120 sentences, and most of them
are easy to understand. It would be a good starting point
for students who need to know how processors work and
for those engineers who wish to design their own
processor. The proposed processor has been physically
tested on Xilinx SpartanIIe FPGAs with a performance
of 40 MIPS in -6C grade devices.
https://hackaday.com/2016/02/24/8-bit-computer-made-solely-from-nand-gates/
Re: Apprendre la programmation en C.
Stauk a écrit:Mon objectif actuel est d'être capable d'écrire des prototypes qui tournent à la fois sous windows et linux, et qui donnent accès à la souris au clavier et à l'écran.
Je suppose que tu as réfléchi à ce dont tu as besoin, mais le choix d'une compatibilité Windows-Linux à l'exclusion de Mac OS, en 2017, c'est un peu déconcertant. Windows, de nos jours, ça a tendance à se cantonner à la machine du prolo désargenté qui ne comprend rien à la technique, voire du retraité de toute façon fâché avec l'informatique, ou alors c'est une machine de bureau gérée par un directeur de parc informatique près de ses sous, et qui n'a qu'une idée: empêcher les utilisateurs de faire tourner autre chose que les logiciels qu'il a choisis pour réduire la masse de travail de la hotline. Dès qu'un utilisateur a trois francs six sous, il s'équipe en Mac, spécialement s'il a moins de cinquante ans. Par ailleurs, le monde windozien a assumé qu'il n'était pas à la pointe de la technique, et généralement il cherche plus à faire survivre des machines vieilles de plus de cinq ans que de s'équiper du dernier cri de la technique.
Par ailleurs encore, l'utilisation des dispositifs mobiles, smartphones et tablettes, a totalement cessé d'être marginale, et ça ne va pas s'arranger dans les années qui viennent.
Tu fais bien comme tu veux, mais par curiosité: pourquoi se focaliser sur Windows? Et d'ailleurs, quelle version de Windows?
Dernière édition par Petitagore le Lun 20 Nov 2017 - 10:19, édité 1 fois (Raison : balise foireuse)
Page 1 sur 3 • 1, 2, 3
Page 1 sur 3
Permission de ce forum:
Vous ne pouvez pas répondre aux sujets dans ce forum