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.

ortolan a écrit:95% du marché des particuliers quand même...

Où l'on parle de stats sur les OS:

ortolan a écrit:Voilà, merci Philippe pour les stats. Je parlais bien du "PC des familles" (prolos, Mme Michu, ça me paraît un peu méprisant).

ZebMcKay a écrit:en 2025 les chinois finiront bien par pondre leur propre os

je m'étonne qu'ils ne l'ait pas encore fait

ZebMcKay a écrit:...
codez ça pour voir... possible en plus, genre si les deux blocs se touchent alors prend le champ 1 du bloc 1 et fusionne le avec le champ 1 du bloc 2
...

Stauk a écrit:Pour ce qui est des stats de qui possède quelle machine équipée de quel système, je serais plus convaincu par une analyse statistique ou autre collecte de donnée, que par un pifomètrisme.

Après faut pas oublier non plus que les usager des ordis ne sont pas cantonnés à la France, ni même aux US.

ortolan a écrit:

Petitagore a écrit:Windows, c'est tellement de la merde que toute mauvaise raison permettant d'y échapper a plus de poids que les statistiques les mieux vérifiées.

Là on tombe d'accord Windows bashing à fond !

Spoiler:

There are significant performance advantages to being 32-byte aligned if you have 32-byte loads and stores, even for instructions that do not require alignment to behave correctly.

Endianness:

Stauk a écrit:Sinon si quelqu'un peut me filer un argument sur comment doivent être alignés les datas sur la plateforme X86, je veux bien prendre. 32 bits ? 128, 256, 512 ?

https://en.wikipedia.org/wiki/Data_structure_alignment

Roger a écrit:

Commencer par programmer une version optimisée est l'erreur classique du débutant. Il vaut mieux commencer par un programme fonctionnel, modulaire, bref, un programme qui marche. Ensuite seulement on optimise. Il est également important de disposer d'options de compilation désactivant certaines optimisations pour que le programme puisse tourner sur le maximum de machines: si il faut le processeur machin-bidule avec tel jeu d'instruction à la mode, c'est mort. De nos jours, les machines sont tellement rapides et ont tellement de mémoire qu'on ne gagne rien à optimiser. Il y a même des optimisations qui ralentissent les programmes... Dans le temps, on mettait en cache les calculs car la mémoire était chère. Aujourd'hui, une telle stratégie plombe les applis à cause des latences d'accès à la mémoire et les fautes de cache: il est aujourd'hui plus efficace de recalculer au lieu de stocker en mémoire.

Roger a écrit:

Stauk a écrit:Petite page de publicité
https://alexgaynor.net/2017/nov/20/a-vulnerability-by-any-other-name/

(bien entendu c'est une publicité anti-C mais bon. Ca met un peu d'ambiance, et puis surtout c'est loin d'être faux).

Le mec fait de la pub pour Rust. Mais il n'a pas réalisé que la sûreté des accès mémoire est un problème réglé depuis l'apparition du premier langage de programmation ou presque: LISP disposait en natif d'un ramasse-miette dès sa conception, en 1958. L'informatique, c'est le grand bon en arrière permanent, la victoires des incultes incompétents.

Roger a écrit: ramasse-miette

Petitagore a écrit:

ortolan a écrit:Voilà, merci Philippe pour les stats. Je parlais bien du "PC des familles" (prolos, Mme Michu, ça me paraît un peu méprisant).

Il se peut. Cela dit, il y a clairement une informatique pour les utilisateurs qui n'y bitent rien, et une informatique pour ceux qui peuvent faire des incursions dans le code -- et ce sont ces derniers qui rédigent les librairies libres, les documentations, les tutoriels. Quand on pond soi-même du code, on a un peu tendance à se désintéresser totalement de la première catégorie, sauf si on veut leur vendre un produit fini. Mais on ne peut pas servir Dieu et Mammon: si on veut faire du bon code, on se fout un peu des machines merdiques, et si on veut vendre au grand public, on se fout un peu de faire du beau code.

Alexandre a écrit:Pour un étudiant en informatique, Linux est souvent le choix parce que pour installer le moindre logiciel, il faut recompiler jusqu'aux entrailles la machine et c'est formateur.

Par ailleurs, il ne faut pas se leurrer : apprendre n'importe quel langage, que ce soit le joyau du fonctionnel comme Ocaml ou une "vraie merde" comme PHP, ça peut certes se faire en quelques heures pour avoir les bases, mais avec ce bagage, on bidouille et c'est tout. Maîtriser "l'art de la programmation", ça ne viendra pas comme ça. Et maîtriser n'importe quel langage, fût-ce cette merdouille de PHP ou de Java, ça demande plusieurs années de pratique. Que ça plaise ou non aux esthètes  . Alors le "mon langage, c'est le plus beau et les autres, y sont tous pourris", ça me fait toujours penser à cette citation de je ne sais plus qui (*) que je paraphraserai en : il y a plus de mauvais programmeurs que de mauvais langages (en proportion) .

(*) De mémoire : "Il y a plus de mauvais pianistes que de mauvais pianos"...

Roger a écrit:

Il y a toutes sortes de ramasses-miettes: interruptibles ou non, multi-threadés ou non, incrémentaux ou non, optimisants ou non, temps-réel ou non. Pour la programmation usuelle, les ramasses-miettes améliorent les performances: ils ne bloquent pas l'application lors de la libération de grosses structures de données, ils défragmentent la mémoire et relocalise les données, ce qui rend les gros caches des processeurs plus efficaces. Mais surtout, ils font totalement disparaître toutes les fuites mémoires, les déréférencements invalides et les failles comme les débordements de pile. Quand on programme des algorithmes complexes, la gestion mémoire devient vite un cauchemar.

Roger a écrit:

Stauk a écrit:Les ramasses miettes peinent un peu, encore de nos jours (2017). C'est excellent pour faire du prototypage rapide, mais par contre dans certains environnements, si tu as du temps réel, ou du temps réel CRITIQUE (genre y a un mec qui meurt à chaque fois que tu es en retard de 2 ms, ou une banque qui fait faillite), les ramasses miettes n'offrent pas toujours toutes les garanties qu'on aimerait avoir. Du moins c'est ce qu'il semblait ressortir sur les forums et autres il y a encore quelques mois.

Pour le mec qui meurt, c'est pas de bol. La banque en faillite, en revanche...

Il y a toutes sortes de ramasses-miettes: interruptibles ou non, multi-threadés ou non, incrémentaux ou non, optimisants ou non, temps-réel ou non. Pour la programmation usuelle, les ramasses-miettes améliorent les performances: ils ne bloquent pas l'application lors de la libération de grosses structures de données, ils défragmentent la mémoire et relocalise les données, ce qui rend les gros caches des processeurs plus efficaces. Mais surtout, ils font totalement disparaître toutes les fuites mémoires, les déréférencements invalides et les failles comme les débordements de pile. Quand on programme des algorithmes complexes, la gestion mémoire devient vite un cauchemar.

Un programme temps réel n'est pas un programme qui va vite, mais un programme qui respecte des contraintes de temps strictes. En général, les systèmes d'exploitation temps réels sont plus lents que leurs homologues plus laxistes. Au niveau des structures de données, le temps-réel impose de bonnes complexités dans le pire des cas, alors que par ailleurs on pourrait privilégier une complexité moyenne encore meilleure. Par exemple, une appli temps-réel utilisera des arbres équilibrés au lieu de tables de hachages, pourtant plus rapides en moyenne. La méthode la plus aisée pour faire du temps réel avec un ramasse-miette est de garantir que ce dernier peut être désactivé à tout moment puis réactivé quand les contraintes temporelles sont moins critiques. De toute manière, le temps-réel est une condition qui demande des soins très particuliers et le ramasse-miette n'est pas le plus dramatique des problèmes: il y a des sources de latence bien plus gênantes et souvent liées au système lui-même.

Roger a écrit:Le relativisme n'est pas pertinent. L'informatique, ça n'est pas n'importe quoi. Il est évident que l'arithmétique en chiffres romains est bien moins bonne que celle en chiffres arabes. Il n'y a pas besoin de tergiverser bien longtemps: un niveau scolaire en calcul suffit pour s'en rendre compte. En informatique, c'est pareil. Sauf qu'en informatique, les professionnels sont très mal formés, complètement ignares de leur discipline et par là même incompétents. J'ai croisé des cas graves, du genre le développeur qui croit avoir programmé un logiciel qui trouve les fuites mémoires dans un code ou qui détecte les programmes qui bouclent... sauf que ce sont des problèmes indécidables, on a les preuves mathématiques de leur impossibilité. Ces mêmes ignorants t'expliquent ce qu'est un bon ou un mauvais langage selon qu'il est cool ou pas. Tout se vaut quand on ne sait pas faire la part des choses. Le relativisme est un symptôme d'incompétence, pas un fanal de liberté.

chocolat a écrit:Je ne sais pas si ça va t'intéresser :
http://pubs.opengroup.org/onlinepubs/9699919799/

N'essayez pas ce mode de communication dans l'open space d'une grande banque:

C'est bien sûr faux, surtout dans l'aéronautique où ils ne veulent pas des langages de haut niveau, ni des méthodes formelles et autres outils de pointe. Ils les connaissent, ils savent qu'avec ces outils, leurs logiciels seraient de meilleur qualité, fonctionneraient mieux et coûteraient moins cher. Mais ils n'en veulent pas. Sont-ils crétins ? Bien sûr que non. Tout simplement, l'adoption de ces outils les forceraient à revoir toutes leurs méthodes et refonder leur chaîne hiérarchique: le chef de projet ne serait plus chef de projet, l'ingénieur ne serait plus ingénieur, etc. Ils veulent conserver leurs privilèges, voilà tout.

Tu n'arriveras pas à me convaincre. Je suis dans la position de celui qui a vu. Je sais ce qu'on apprend aux informaticiens, je sais ce qu'ils font une fois embauchés et je sais qui leur donnent des ordres. Ces gens sont des ignares, ils ne savent rien, ce sont de simples bricoleurs du dimanche bombardés développeurs. Les plus mauvais deviennent managers et font ensuite les choix stratégiques qui coûtent des milliards à la communauté. Les plus mauvais managers deviennent business angels et financent les équipes aux commandes des fondations Mozilla, de Google, ils font du PHP, du Go, de l'AutoIt, toutes ces merdes.

Writing Secure Code

Page 102 :
size_t __builtin_object_size(void *ptr, int type)