Journal C11, listes variantes et le turfu

Posté par  (site web personnel) . Licence CC By‑SA.
26
13
mai
2024

Salut' nal,

Dans la foulée, pas immédiate, des excellents articles de pulkomandy sur les évolutions du langage C, j'ai décidé de m'intéresser à… C11.

Oui seulement lui ; car ça fait peut-être déjà 12 ans, mais l'adoption du truc reste relativement récente

En tant que développeur C++, revenir aux "bases" m'a fait du bien. Pas de références universelles à transmettre à travers des couches de templates, pas d'instanciation de générique avec un type privé, pas de surcharge-surprise des opérateurs…

([gueule]et pis j'ai récemment eu des échos des cours de C à l'univ et là… franchement ! On leur explique ni la pile ni le tas, "faisez des tableaux[1024] et ça passera", "_Tu utilises le "bool" de stdbool.h> ? C'est pas un peu trop récent ?"… RHaahaaaaa! Ça sent un mélange de condescendance et de naphtaline toussa… 🤬[/gueule])

Je te propose donc un petit composant, pas optimisé mais cependant fonctionnel et normalement thread-safe :

variant_list

c'est-à-dire une liste dynamique d'éléments hétérogènes, qui supporte : les Entiers, Booléens, Flottants et Chaînes.


L'intérêt est surtout qu'il démontre pas moins de 5 features du C11 ! Les voici :

1. macros _Generic

La principale innovation ! Ce code :

#define list_add(L, V) _Generic((V), \
    int:    list_add_int, \
    bool:   list_add_bool, \
    double: list_add_float, \
    char*:  list_add_string)(L, V)

nous permet d'écrire :

list_add(l, 42);     // entier
list_add(l, true);   // booléen
list_add(l, 3.14);   // flottant
list_add(l, "Toto"); // chaîne

un début -même timide- de polymorphisme en C, et ça régale !

2. Threads cross-platform

C'est quand même bien d'avoir des threads utilisables sur tous les OS…

#include "<threads.h>

typedef struct
{
     ...
     mtx_t locked;         // C11
}

mtx_init(&l->locked, mtx_recursive | mtx_timed);
mtx_lock(&list->locked);
 ...
mtx_unlock(&list->locked);

3. struct timespec

Alors ça c'est lié, même si ça paraît n'être qu'un type "temps" de plus. En fait ça permet de faire ça :

struct timespec ts;            // C11
timespec_get(&ts, TIME_UTC);   //  heure actuelle...
ts.tv_sec += 1;                //  ... + 1 seconde

mtx_timedlock(&list->locked, &ts); // attend 1 seconde si c'est occupé !

et a sûrement été ajouté à la norme pour cette raison précise.

4. structs/unions anonymes

C'est une facilité qui permet de s'adresser directement au "contenu" des structs/unions à travers une hiérarchie, à conditions qu'elles n'aient pas de nom propre :

struct Value
{
    union { int i; bool b; double f; char* s; }; // C11: anonyme
    ...

struct Value v;
v->i = 42;      // comme si "i" était directement dans "v"

et dans notre contexte de "variant", on s'en sert bien sûr à mort 😉.

5. _Static_assert()

Du code C de test à la compilation ! Tant que les valeurs sont éligibles au static const :

_Static_assert(sizeof(NULL) == sizeof(void(*)()), "NULL n'est pas un pointeur, allô ?");

annonciation du futur "nullptr" de C23, nous sert notamment à vérifier le terrain pour la future surcharge:

    double: list_get_float, \
    char*:  list_get_string, \
    void*:  list_get_Type)(L, V) // à faire !

qui nous permettra d'obtenir des infos sur les éléments sans variable ni réinventer la roue.

(C23 renomme en "static_assert()" et aura aussi "constexpr" qui permettra bien d'autres choses)


Voilatou !
Okazou, j'ai également fait une version bibliothèque du composant.

Je pense éventuellement le faire évoluer pour rajouter ce dont j'ai parlé ci-dessus, ainsi que les quantités d'arguments variables ("varargs") :

list_add(l,  42, true, 3.14, "Toto"); // autant d'arguments qu'on veut !

et peut-être même, un jour, de l'optimisation…
… sortie de la prod' où tout est plus rapide mais plus laid 😉 .

  • # Génération Z

    Posté par  . Évalué à 8.

    C'est pas un peu trop récent ?

    Oh là là, tu utilises des // pour commenter du code C, à la place des /* */ ? C'est un peu cavalier quand même, ça ne passera pas sur tous les systèmes.

    Blague à part, j'ai récemment accompagné un jeune à se préparer pour entrer dans l'école 42, et cette syntaxe aventureuse n'est pas acceptée. Elle est standard depuis 1999. Je cherche toujours une explication plausible…

    • [^] # Re: Génération Z

      Posté par  (site web personnel, Mastodon) . Évalué à 10.

      Je cherche toujours une explication plausible…

      Si c’est la même explication que les règles idiotes de la « piscine » d’Epitech (~modèle de 42), le but pédagogique derrière est surtout d’être capable de programmer en respectant des règles arbitraires, et absolument pas d’apprendre à bien programmer (et on est pas censé continuer à respecter ces règles au-delà).

      Quant à l’intérêt pédagogique réel (de ces règles comme de la « piscine » en général), je vous laisse seuls juges – mon avis ne peut pas s’exprimer ici sans tomber dans la grossièreté.

      La connaissance libre : https://zestedesavoir.com

      • [^] # Re: Génération Z

        Posté par  (site web personnel) . Évalué à 2.

        Pourtant, on a tous du bien à dire de 42 😉.
        Car le bien étant le juste milieu, il s'applique bien à la proportion de 50% des profils qui en sortent !

    • [^] # Re: Génération Z

      Posté par  (site web personnel) . Évalué à 4. Dernière modification le 14 mai 2024 à 08:13.

      Oh là là, tu utilises des // pour commenter du code C, à la place des /* */ ? C'est un peu cavalier quand même, ça ne passera pas sur tous les systèmes.

      On me disait déjà ça dans mes cours, quand 1999 était pourtant trèèès passé 😄.

      Je pense que c'est un conservatisme "de fait" qui s'appuie sur la transmission informelle plutôt que sur la normalisation formelle :
      très peu fréquente et mal suivie en C, une tous les 10 ans ; en C++ c'est important et tous les 3 ans maxi.

      Les profs de C reproduisent le code du Grand Schtroumpf ; pour les innovations ils considèrent que c'est pas chez eux et t'envoient vers leurs collègues Java qui savent pas compiler sans IDE ("t'en auras jamais besoin").
      (au fait, on t'a dit que j'aimais pousser des [gueule] au fil de l'eau ?)

      • [^] # Re: Génération Z

        Posté par  . Évalué à 5.

        leurs collègues Java qui savent pas compiler sans IDE ("t'en auras jamais besoin").

        Ouais, après, je suis pas convaincu qu’il y ait grand monde qui lancé javac directement ces 15 dernières années. C’est même pas une question d’ide, tout le monde (y compris les ide) déléguent cette tâche à maven.

        C’est probablement techniquement possible de compiler la plupart des projets Java à la main, mais je suis franchement pas convaincu de l’intérêt.

        Linuxfr, le portail francais du logiciel libre et du neo nazisme.

        • [^] # Re: Génération Z

          Posté par  (site web personnel) . Évalué à 5.

          Je l'ai fait dans l'encadrement de TP d'info. J'espère ne pas être seul, et que nous sommes légions. :)

          Adhérer à l'April, ça vous tente ?

        • [^] # Re: Génération Z

          Posté par  . Évalué à 3.

          Ouais, après, je suis pas convaincu qu’il y ait grand monde qui lancé javac directement ces 15 dernières années.

          D'autant que les cas où ça pouvait permettre de faire très simplement des choses simples n'existent presque plus puisque tu peut "lancer" un fichier .java simplement avec

          java MaClasse.java

          C’est même pas une question d’ide, tout le monde (y compris les ide) déléguent cette tâche à maven.

          Sauf intellij et eclipse. Ils tentent d'être plus malins que maven et d'ailleurs ne cherchent pas à être trop lié à ce dernier mais ils ont une bonne intégration et tu n'a pas à savoir ce qu'ils font dans l'énorme majorité des cas. Tu manipule juste des pom.xml et c'est terminé.

          Je pense que le commentaire au dessus parlait de cas de ne pas savoir ni compiler ni lancer le programme sans l'IDE. Je ne sais pas ce qu'il en serait aujourd'hui mais fut un temps si tu te laissais portait par l'IDE sans chercher à comprendre, tu cliquait juste sur un bouton play et tu n'avais aucune idée de ce qui se passait derrière.

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: Génération Z

            Posté par  . Évalué à 3.

            Sauf intellij et eclipse. Ils tentent d'être plus malins que maven et d'ailleurs ne cherchent pas à être trop lié à ce dernier mais ils ont une bonne intégration et tu n'a pas à savoir ce qu'ils font dans l'énorme majorité des cas. Tu manipule juste des pom.xml et c'est terminé.

            Ben, dans l’ensemble, c’est un javac de tout ce qu’il y’a sous main/src et main/test. Le problème, c’est les dépendances, et c’est pas IntelliJ/eclipse qui va les chercher, ça fait juste tourner un mvn.

            Je pense que le commentaire au dessus parlait de cas de ne pas savoir ni compiler ni lancer le programme sans l'IDE. Je ne sais pas ce qu'il en serait aujourd'hui mais fut un temps si tu te laissais portait par l'IDE sans chercher à comprendre, tu cliquait juste sur un bouton play et tu n'avais aucune idée de ce qui se passait derrière.

            C’est précisément mon point. Ça fait 20 ans que je fais du java professionnellement (la vache, ça pique!), je serais absolument incapable de builder mon appli a la mano. Et par dessus tout, ça serait complètement con.

            Idem pour lancer l’appli à la main, mvn exec:java, et encore je vais me ramasser sur la syntaxe (je sais qu’il y’a un exec, mais probablement pas java, et je sais aussi que mes variable -D vont passer à la trappe).

            Linuxfr, le portail francais du logiciel libre et du neo nazisme.

        • [^] # Re: Génération Z

          Posté par  (site web personnel) . Évalué à 7. Dernière modification le 14 mai 2024 à 20:17.

          C’est probablement techniquement possible de compiler la plupart des projets Java à la main, mais je suis franchement pas convaincu de l’intérêt.

          En fait, c'est moins une question d'utilité (car moi aussi je me sers de l'IDE 24H/24) que de pédagogie.

          Quand c'est ton 1er cours de Java, que tu demandes à ton prof comment compiler ton projet constitué d'un seul .java ; et qu'il te répond qu'il sait pas, que de toute façon on va utiliser Eclipse… Précision supplémentaire : il n'a pas non plus cité maven, ni gradle, ni aucun outil du genre.

          Notre taf (qui est aussi pour certains notre passion) est basé sur des couches qui s'empilent.
          Ne pas évoquer les couches de base, au moins durant la phase d'apprentissage, c'est rendre l'élève captif d'un empilement ad hoc qu'il sera incapable de reconstruire à sa façon si on le change de terrain. À mon humble avis.

          • [^] # Re: Génération Z

            Posté par  . Évalué à 4.

            Ne pas évoquer les couches de base, au moins durant la phase d'apprentissage, c'est rendre l'élève captif d'un empilement ad hoc qu'il sera incapable de reconstruire à sa façon si on le change de terrain. À mon humble avis.

            Je ne pense pas. Personne n'est captif d'un IDE. Celui au quel on pense tous avec java et un gros bouton play c'est eclipse. Projet libre pas relié à une entreprise et personne hors études se retrouve enfermé avec eclipse (au point où jetbrain - très peu présent dans le monde universitaire en tout cas français - a pu arriver et lui tailler des croupières). Parce qu'en fait c'est relativement simple. Le sujet de compiler du code java n'existe pas vraiment. Tu as des outils de builds différents mais qui se démarquent pour des choses autour de ça. pour ce qui est de compiler du java, c'est un sujet résolu (en bytecode tout du moins).

            Tu as des IDE qui enferment : xcode par exemple, mais aussi les platefrome à la mode dans les années 90 (delphi ? smaltalk ?), mais dans le monde java je ne crois pas.

            Je gèrerais un cours de programmation java, je préfèrerais probablement garder plus de temps sur du code que de prendre du temps d'une part qui ne leur servira quasiment que s'ils font du java et qu'ils apprendront en arrivant en entreprise très surement.

            https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

            • [^] # Re: Génération Z

              Posté par  (site web personnel) . Évalué à 3. Dernière modification le 14 mai 2024 à 21:25.

              Je pense qu'on ne va pas être d'accord là-dessus.
              Notamment quand tu dis:

              pour ce qui est de compiler du java, c'est un sujet résolu (en bytecode tout du moins).

              Résolu en pratique, d'accord.
              Mais il y a bien un truc qui le fait, qui doit le faire, à un moment donné; et comment le fait-il ?
              Ne pas répondre à cette question au moins une fois ; à mon sens, c'est un manquement majeur.

              L'équivalent en TypeScript serait de ne pas expliquer qu'il existe un transpileur nommé "tsc" qui transforme les .ts (que le développeur écrit) en .js (que le navigateur charge).
              On peut vivre sans, juste écrire le bousin, cliquer sur le bouton, et recharger la page ; mais ça ne permet pas de qualifier au titre d'expert AMHA.

              En fait ça limite le développeur à la tâche d'écriture du code, sans notion de l'environnement en-dessous.
              Et je dis bien "limite", sans doute parce que je considère ça insuffisant.

              • [^] # Re: Génération Z

                Posté par  . Évalué à 2.

                pour ce qui est de compiler du java, c'est un sujet résolu (en bytecode tout du moins).

                Résolu en pratique, d'accord.
                Mais il y a bien un truc qui le fait, qui doit le faire, à un moment donné; et comment le fait-il ?
                Ne pas répondre à cette question au moins une fois ; à mon sens, c'est un manquement majeur.

                En fait (pour le cas de java) la question est tellement trivial que c'est vraiment facile à trouver par soit-même ou de se faire aider par un collègue ou ce que tu veux comme autre source d'information. Alors que comprendre ce qu'est l'orienté objet à la fin du module tu aura 30% de la promo qui ne le comprendront pas et tu vois des gens qui s'écharpe depuis des décennies dessus. Entre arriver à aider un peu plus 2 ou 3 élèves à comprendre comment utiliser le paradigme derrière le langage et en perdre 2 ou 3 avec de la technique je pense que mon choix est vite fait.

                […] mais ça ne permet pas de qualifier au titre d'expert AMHA.

                Les études ne forment pas des experts. Tu acquière l'expertise après des années de pratiques.

                En fait ça limite le développeur à la tâche d'écriture du code, sans notion de l'environnement en-dessous.
                Et je dis bien "limite", sans doute parce que je considère ça insuffisant.

                En fait tu ne prend pas en considération le contexte. Tu as un module il fait quelques heures, tu va voir comment avance les étudiants, il y a un moment où tu va devoir choisir tu retire quoi ?

                • comment on appel le compilateur ?
                • la généricité ?
                • le polymorphisme ?
                • les lambda ?
                • l'utilisation des annotations ?
                • les tests ?
                • comment utiliser les exceptions ?

                Oui tu ne va pas former des cracks qui se vendront 70k en sorti d'étude, il y a des trucs qu'ils n'auront pas vu, des trucs qu'ils auront mal appris et des trucs qu'ils auront totalement oublié dans la semaine qui suit le diplôme.

                https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                • [^] # Re: Génération Z

                  Posté par  (site web personnel) . Évalué à 2.

                  D'accord, si le critère n°1 est le temps, pourquoi pas.

                  former des cracks qui se vendront 70k en sorti d'étude

                  J'ai presque envie de troller en disant que pour ça, ce n'est pas du Java qu'il faut faire,
                  mais du Rust/C++/Swift 😁.

                • [^] # Re: Génération Z

                  Posté par  (site web personnel) . Évalué à 6. Dernière modification le 15 mai 2024 à 07:54.

                  Tu as un module il fait quelques heures, tu va voir comment avance les étudiants, il y a un moment où tu va devoir choisir tu retire quoi ?

                  Je ne retire rien, je condense ou je demande une rallonge de temps.

                  Aujourd'hui un développeur qui sait programmer mais ne maîtrise pas la construction d'un projet (dépendances, gestion de version, CI/CD…), c'est aussi utile qu'un garagiste qui connait la mécanique mais ne sait pas utiliser une valise de diagnostic.

                  Nos métiers sont plus complexes, les formations doivent s'adapter.

                  Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                  • [^] # Re: Génération Z

                    Posté par  . Évalué à 1.

                    Condenser c'est à la fois retirer du contenu et perdre une partie de la promo. Pour ce qui est de demander du temps, je te laisse te confronter aux réalités d'une université.

                    Nos métiers sont plus complexes, les formations doivent s'adapter.

                    Franchement non. Mon métier n'est pas drastiquement plus complexe qu'il y a 15 ans (et j'ai commencé par du JavaEE Oracle à tous les étages à du kubernetes on premise avec spring et vertx déployé dessus). Il a changé, mais de là à le présenter comme plus complexe c'est se fourvoyer amha.

                    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                    • [^] # Re: Génération Z

                      Posté par  . Évalué à 3.

                      Il a changé, mais de là à le présenter comme plus complexe c'est se fourvoyer amha.

                      Si on regarde sur 40 ans, je pense que l'IT moderne est effectivement plus complexe que dans les années 90 ou le début des années 2000, et ce principalement pour la raison des exécutions en parallèle.
                      La prévalence des interactions réseau, aussi. Je suis persuadé (pas convaincu, persuadé, autrement dit, ça repose sur l'affect et non une démarche objective) que même si il y avait du réseau il y a 40 ans (je sais que c'est le cas, merci) il était nettement moins utilisé dans les applications, et la complexité qu'ajoute une connexion réseau n'est pas un truc que j'ai halluciné: établir une connexion a un serveur, et vérifier qu'elle est en bon état, la redémarrer ou la maintenir, ce n'est pas simple. Ajoutons à ça la communication radio (a comparer a des paires de cuivre, la stabilité n'est pas la même), les capacités des processeurs qui font que de nos jours, la bande passante entre la RAM et le CPU est l'un des goulots d'étranglement classique avec un CPU qui glande a 80% du temps (avant, l'idée était plutôt d'éviter de cramer des cycles pour rien, quitte a utiliser de l'assembleur inline), et probablement de nombreux problèmes que j'oublie, oui, je pense que l'informatique moderne est plus complexe.

                      Certes, avant (80s, début des 90s) il n'y avais pas de directX, il fallait piloter directement le matériel dans certaines applications pour lesquelles ce n'est plus nécessaire (jeux sous ms-dos par exemple. Oui, je sais, on pilote toujours le matériel dans certaines applications, mais c'est enlever la catégorie des jeux vidéo vire déjà une bonne partie de l'offre logicielle) et il était plus difficile d'accéder à du code fait par autrui pour se faciliter le travail, mais je ne crois pas que ça compense, vu qu'avant, trouver un manuel ou une référence potable pour un produit, ce n'était pas la croix et la bannière (parce que c'était livré avec, tout simplement).
                      On peut aussi mentionner le fait que les langages étaient beaucoup moins bien foutus et les compilateurs moins performants, mais pareil, ça me semble pas compenser l'augmentation de la complexité des programmes.

                      Après, on peut aussi arguer que le dev, il fera du frontend ou utilise un langage type python qui fait tout magiquement et donc la perf il s'en balance, mais… bon, primo, ça dépend du milieu dans lequel le dev évolue, et secondo moi, ça me dérange très fortement cette attitude. Rapport a jeter du matériel qui pourtant marche parfaitement, juste parce qu'une personne a voulu ajouter des coins arrondis simulés par de la transparence, des effets de transitions qui font perdre du temps à l'utilisateur, ou des publicités qui te sautent à la gueule.

                      Concrètement, les couches logicielles sont plus simples à utiliser, mais je pense clairement que l'infrastructure IT est largement plus complexe, ce qui se reflète nécessairement sur le métier.
                      Pour les méthodes utilisées, je ne sais pas, je n'avais pas assez d'expérience pour juger, il y a 15 ans, mais ça, ça change d'entreprise en entreprise de toute façon.

                      • [^] # Re: Génération Z

                        Posté par  . Évalué à 2.

                        Si on regarde sur 40 ans

                        D'une part, tu parle sur des temps que je ne connais pas, d'autres part tu parle sur des temps qui dépassent le temps des formations. Tu ne peux pas dire que les formations en informatiques n'ont pas évoluées entre le début des années 90 et maintenant. Donc je ne vois pas en quoi c'est pertinent dans la discussion.

                        Je n'ai pas dis que l'informatique ne s'est jamais complexifié, j'ai dis que sur les 15 ans que je peux vérifier (qui sont du vécu et pas de l'ordre de l'imagination) je n'ai pas l'impression que ça se soit sensiblement complexifié.

                        Concrètement, les couches logicielles sont plus simples à utiliser, mais je pense clairement que l'infrastructure IT est largement plus complexe, ce qui se reflète nécessairement sur le métier.

                        Ça n'impacte qu'une fraction des développeurs actuels et encore ça devrait être mis en balance avec la réduction du nombre de plateforme (plus grand monde travail sur du MIPS par exemple) que les couches basses font un gros travail d'abstraction que tu n'avais pas à l'époque (même pas trop basse, hein, les erreurs de g++ il y a 15 ans et maintenant c'est le jour et la nuit), que le matériel est plus fiable (tu as moins de chance d'avoir une casse matériel lié à ton code - même si ça peut toujours exister -) et maintenant tu as une abondance dans l'accès à internet ce qui a probablement drastiquement changé les métiers.

                        Sur 15 ans l'informatique s'est complexifiée oui, est-ce que globalement le boulot s'est complexifié ? J'en doute. Tu as des cas qui se sont complexifié, mais ils ne représentent pas la majorité amha

                        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                        • [^] # Re: Génération Z

                          Posté par  . Évalué à 3. Dernière modification le 04 juin 2024 à 13:18.

                          J'ai aussi moins de 40 ans, mais je me souviens très bien des PC de mon enfance.

                          Je n'ai jamais dis que les formations n'ont pas évolué, par exemple je n'ai pas appris l'assembleur en terminale électronique, mais le C, alors que mon père, qui a fait la même classe 15 ans plus tôt, avait de l'assembleur motorola.
                          Je doute aussi qu'UML existait il y a 40 ans, par contre merise oui. J'ai découvert UML en BTS, et merise dans une formation plus tard (et j'ai plus utilisé merise à des fins réellement utiles dans ma vie qu'UML… amusant constat).

                          Je n'ai pas dis que l'informatique ne s'est jamais complexifié, j'ai dis que sur les 15 ans que je peux vérifier (qui sont du vécu et pas de l'ordre de l'imagination) je n'ai pas l'impression que ça se soit sensiblement complexifié.

                          Je pensais que l'on parlais du métier, pas des formations. Je n'avais pas compris la limite sur les 15 ans, non plus.
                          Donc, mes excuses. Problème de compréhension de ma part.

                          même pas trop basse, hein, les erreurs de g++ il y a 15 ans et maintenant c'est le jour et la nuit),

                          Ah ça c'est clair, je me souviens très bien de l'horreur qu'était comprendre une erreur dans un template!

                          • [^] # Re: Génération Z

                            Posté par  . Évalué à 2.

                            Ah ça c'est clair, je me souviens très bien de l'horreur qu'était comprendre une erreur dans un template!

                            J'ai le souvenir marquant d'avoir passé beaucoup de temps sur un foutu point virgule manquant en fin de classe template. J'ai l'impression que c'est l'une des choses que clang a fait bouger.

                            https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                            • [^] # Re: Génération Z

                              Posté par  . Évalué à 2.

                              Clang, et surtout C++11. En fait, je pense que clang a simplement adopté les erreurs améliorées avant qu'elles ne soient dans le standard officiel, même si c'était dans le draft de C++0x.

                              Ça et la performance du compilateur sont les 2 raisons qui m'ont fait adopter clang pour mes builds itératifs. Pour les builds de release, je me contente d'utiliser g++ sans trop réfléchir, parce qu'il paraît que les binaires générés sont mieux optimisés. Mais je n'ai jamais vérifié ça moi même.

                      • [^] # Re: Génération Z

                        Posté par  . Évalué à 3.

                        On peut aussi mentionner le fait que les langages étaient beaucoup moins bien foutus et les compilateurs moins performants, mais pareil, ça me semble pas compenser l'augmentation de la complexité des programmes.

                        Je pense que tu confonds cause et effet. La complexité des programmes a monté, oui, mais c'est surtout une consequence du tooling et des fondations (compilos y compris) qui a vraiment monté en puissance, en parallèle du hardware.

                        Le multi threading sur un CPU single core, effectivement, ca servait pas forcement a grand chose, a part laisser le main thread redessiner l'interface. Les modèles de programmation reactive servent pas forcement a grand chose sur des applis qui n'ont pas besoin de constamment se mettre a jour sur un flux de données constamment mises a jour (ce qui rejoint ton point sur la prevalence du réseau avant). L'état de l'art était pauvre, et les technique de programmation reflétaient ca. Quand les besoins se sont fait clair, on a tâtonné un peu, et fini par avoir des bases tres solides, qui permettent de se concentrer sur l'essentiel.

                        Je vais pas prétendre que les bugs de memory management ont disparu, mais ils deviennent des plus a plus dur a écrire (ARC dans le monde apple qui a eliminé 99% des problèmes, java/python etc, meme c++ te met des auto partout).

                        Le réseau a été abstrait par des couches robustes, t'as maintenant du multipath qui passe d'une interface a l'autre sans que l'application au dessus ne se rende compte de ce qu'il se passe.

                        Bref, tout ca pour dire, la complexité a monté, oui, mais surtout, elle a muté. On est passé d'une complexité accidentelle (synchroniser l'acces a une variable globale depuis plusieurs thread), a une complexité essentielle (envoyer des closures sur des queues, qui ne modifient qu'un état prive, non partagé). Tu peux toujours te mettre au tas, ou deadlocker, oui, mais dans l'ensemble, c'est vachement plus dur a fair maintenant qu'il y a 10 ans.

                        Linuxfr, le portail francais du logiciel libre et du neo nazisme.

              • [^] # Re: Génération Z

                Posté par  . Évalué à 2.

                Ne pas répondre à cette question au moins une fois ; à mon sens, c'est un manquement majeur.

                Ouais, comprendre la chaîne de compilation, c’est important. Mais aussi, pas tant que ça. Sur du java/javascript/python, y’a pas forcément grand chose de subtil, et en 20 ans, j’ai jamais eu un seul problème la dessus. Tout est dynamique, on s’en fout du layout en mémoire (sorti de trucs bizarres comme la serialization, mais c’est assez extrême comme example).

                Sur un cours c/c++/objc/swift, la oui, ça me paraît indispensable, parce que ça va très vite te peter à la gueule si tu comprends pas ce qu’il se passe. Je suis le gars de service qui explique pourquoi le build a pété, pourquoi non, on va pas static linker une librairie dans 4 extensions, et pourquoi le runtime gueule comme un putois d’avoir des symboles en double à cause dudit static link de partout. Et me lance pas sur les Bitcode, le simulator meme sur un m1 est une arch différente, et non, tu peux pas juste linker, juste parce que la méthode existe dans les 2, le layout est pas le même et ça va te peter à la gueule.

                Mais, aussi, je vois une armée de dev java/js/.net à côté qui s’en battent les steaks de leur chaîne de compilation et ont jamais eu le moindre souci en 15 ans de carrière. Disons que c’est un peu choquant pour les vieux de la vieille, mais dans ce monde moderne de runtime, bytecode et interpreteurs jit, c’est loin d’être le plus important.

                Pour être tout à fait honnête, je préférerais de très, très, très loin qu’on arrête d’enseigner que l’oriente objet, c’est l’héritage, parce que ça fait beaucoup plus de dégâts que de ne pas savoir lancer javac à la mano. J’te jure, le prochain nouveau diplômé qui m’explique qu’une voiture c’est un véhicule, et que donc c’est polymorphique avec des camions, des motos et le vélo à petites roue de mon fils, je vais peter une durite.

                Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                • [^] # Re: Génération Z

                  Posté par  . Évalué à 1. Dernière modification le 14 mai 2024 à 23:39.

                  fait beaucoup plus de dégâts que de ne pas savoir lancer javac à la mano

                  Souffler sur un pissenlit fais plus de dégât que de ne pas savoir lancer javac.

                  Disons que c’est un peu choquant pour les vieux de la vieille, mais dans ce monde moderne de runtime, bytecode et interpreteurs jit, c’est loin d’être le plus important.

                  En fait la question c'est qu'elle est ton travail ? Est-ce que c'est écrire le code qui tire le mieux parti possible de l'architecture sur le quel il tourne ou est-ce que c'est par exemple le fait de sortir certaines fonctionnalités aux utilisateurs ? (vraiment il ne faut pas y voir du manichéisme de ma part les 2 ont de la valeur et c'est d'un côté ce que l'on te demande et de l'autre comment toi tu envisage ton travail) C'est ça qui devrait déterminer le runtime et le temps que tu alloue à chaque chose. Sachant que si tu as des dev c++ qui s'intéressent au hardware autant que des dev js, c'est pas garanti que l'on gagne grand chose sur le résultat final.

                  Bien sûr le monde n'est pas totalement figé, il n'y a pas longtemps en java j'ai pu gagner de la performance nécessaire en cas d'utilisation réel parce que je sais comment fonctionne le modèle mémoire du langage.

                  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                • [^] # Re: Génération Z

                  Posté par  (site web personnel, Mastodon) . Évalué à 8.

                  Ouais, comprendre la chaîne de compilation, c’est important. Mais aussi, pas tant que ça. Sur du java/javascript/python, y’a pas forcément grand chose de subtil, et en 20 ans, j’ai jamais eu un seul problème la dessus. Tout est dynamique, on s’en fout du layout en mémoire (sorti de trucs bizarres comme la serialization, mais c’est assez extrême comme example).

                  J'ai travaillé sur des projets ou la chaîne de compilation sur les serveurs de build était obligée de lancer un Eclipse parce que les développeurs avaient écrits certains de leurs outils de build sous forme de modules Ant qui appelaient des API de Eclipse et ça ne marchait que dans le contexte de l'IDE.

                  Alors il n'est certainement pas nécessaire que tout le monde dans l'équipe comprenne comment ça fonctionne dans le détail, mais pour ce genre de choses, c'est peut-être pas mal d'avoir au moins une vague idée de ce qu'il se passe.

                  • [^] # Re: Génération Z

                    Posté par  . Évalué à 0.

                    Mais là ce que t'es entrain de dire c'est qu'une équipe a fait le choix délibéré d'avoir un build sophistiqué. C'est un peu comme dire que ça peut être utile de connaitre perl parce que j'ai déjà vu une équipe faire son build en perl.

                    Surtout que ce qui est nécessaire c'est plus de connaitre le principe d'une CI que de comment tu lance javac qui ne va pas t'aider quand tu te retrouve devant une API d'eclipse amha

                    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                • [^] # Re: Génération Z

                  Posté par  . Évalué à 7. Dernière modification le 15 mai 2024 à 15:02.

                  Sur du java/javascript/python, y’a pas forcément grand chose de subtil

                  Je ne connais pas Java, mais je suis en désaccord assez profond à propos de Python. C’est bourré de subtilités, quand un script Python tourne, ça n’a rien d’évident de savoir où il est allé charger ses modules (pip système, pip utilisateur, conda, venv, etc) et quel interpréteur Python il utilise. Ta remarque me fait penser que tu ne dois pas beaucoup enseigner, parce-qu’un débutant qui a installé Spyder via Anaconda ou chargé son script dans VSCode a rarement la chance que son code tourne du premier coup, sauf éventuellement, s’il n’utilise aucun module que les plus courants et il n’a alors absolument aucune idée de ce qu’il fait (et par conséquent de comment faire fonctionner son script sur un autre ordinateur).

                  Déjà, après le clic sur la flèche verte de VScode ou Spyder, ce n’est pas évident pour tout le monde de comprendre quel est le dossier d’exécution du script. À l’inverse, si tu commences un cours avec un éditeur de texte, et en appelant explicitement python monpremierscript.py, toutes ces notions apparaissent simplement et se comprennent facilement.

                  • [^] # Re: Génération Z

                    Posté par  . Évalué à 6.

                    Un xkcd pour illustrer ton commentaire:
                    xkcd 1987

                  • [^] # Re: Génération Z

                    Posté par  (site web personnel) . Évalué à 2. Dernière modification le 15 mai 2024 à 16:48.

                    Très bon 😁.

                    Sans sarcasme, mais quand même: pour avoir déjà pratiqué le serpent, l'"environnement Python stable et reproducible" est effectivement un challenge en soi.
                    Immpensable de faire des déploiements sans maîtriser les préfixes, les venvs, au pire les dockers qui vont bien.

                  • [^] # Re: Génération Z

                    Posté par  . Évalué à 3.

                    Je ne connais pas Java

                    Aujourd'hui la pratique consiste à utiliser un "équivalent" du binaire statique avec ce qu'on appel des fatjars (ou uberjar). C'est un zip qui contient ton code compilé (des fois le source), tes dépendances et un ou 2 fichiers qui décrivent le truc.

                    Sur un jar comme ça tu peux simplement faire java -jar fichier.jar et c'est clos. Quel java ? Tu peux bien sûr faire java --version, mais comme il n'y a pas de bibliothèque dans le JRE (hors la bibliothèque standard), ils sont tous interchangeables (tu as une suite de tests qui est là pour le vérifier).

                    Tu n'a pas java ou pas la bonne version ? Tu le télécharge, le décompresse, set la variable JAVA_HOME dans le dossier que tu viens de créer et tu lance ${JAVA_HOME}/bin/java.

                    Comme java est de base très découplé du système ça n'est pas un gros problème.

                    Je dirais qu'en python tu dois faire des pieds et des mains pour te dépatouiller du système (avec les différentes formes d'env, etc) en java c'est les mainteneurs de distribution qui se tapent le sale boulot pour tordre java pour en faire des paquets systèmes (c'est pas la mère à boire mais tu sent que c'est pas fait pour).

                    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                • [^] # Re: Génération Z

                  Posté par  . Évalué à 8.

                  Le fait que tu pétes une durite™, quand on te parle de l'objet véhicule, montre que c'est héritable.

                  Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr

        • [^] # Re: Génération Z

          Posté par  . Évalué à 3.

          je l'ai fait y'a pas longtemps pour vérifier certains comportements sur des classes de tests et valider des hypothèses.

          Si tu fais un truc rapide hors ide, avec que quelques fichier, sortir maven ou autre sera bien plus chiant.

          note bien doit aussi y'avoir moyen de passer par make et ses règle auto ;)

          Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: Génération Z

      Posté par  (Mastodon) . Évalué à 3.

      Diantre, j'ai commencé à coder en C en 1991, et j'utilisais déjà les deux syntaxes de commentaires, je crois les avoir toujours connues…

      • Yth.
  • # Notes

    Posté par  (site web personnel) . Évalué à 4.

    Okazou, j'ai également fait une version bibliothèque du composant.

    Sous licence GPL, pour une bibliothèque c'est la plaie. Personne ne va l'utiliser, au pire LGPL.

    #undef  true
    #undef  false
    #define true  ((_Bool)+1)
    #define false ((_Bool)+0)

    En C23 tout cela devient des keywords, donc à éviter.

    C'est quand même bien d'avoir des threads utilisables sur tous les OS…

    Bof, les C11 threads sont extrêmement limités. En vrai personne ne les utilise et on préfère pthread la plupart du temps (quand on a pas besoin de portabilité) parce que les C11 threads n'ont pas de read-write lock (comme pthread_rwlock) et c'est dommage car c'est quand même pratique.

    Il y a aucune fonction pour afficher les erreurs en chaine de caractère donc on peut pas faire un convivial perror ni strerror(errno).

    On a aucune garantie de ce qui s'applique avec ces threads (partage des signaux bloqués, etc).

    Autre note en vrac, pourquoi des script shell pour compiler du code et pas un Makefile/ CMake ?

    git is great because linus did it, mercurial is better because he didn't

    • [^] # Re: Notes

      Posté par  (site web personnel) . Évalué à 2. Dernière modification le 14 mai 2024 à 09:44.

      Hello David,
      Merci pour ton comm, je prends ça dans l'ordre !

      Sous licence GPL, pour une bibliothèque c'est la plaie. Personne ne va l'utiliser, au pire LGPL.

      Très bonne remarque ! J'avais oublié ça en générant la version "library" de la chose.
      Je regarde pour changer les headers et mettre un COPYING approprié dans le répertoire.

      En C23 tout cela devient des keywords, donc à éviter.

      Excellente remarque également. Je vais les #ifdef-garder.
      (NB: j'ai prévu une version C23 pour quand j'aurai accès à un compilo capable. Ça me permettra de tester toussa)

      Bof, les C11 threads sont extrêmement limités. En vrai personne ne les utilise et on préfère pthread la plupart du temps

      Je suis d'accord sur le fait que c'est une version appauvrie des pthreads (sur lesquels ils sont en réalité basés au runtime).
      Perso je ne me sers pas de toutes leurs fonctions, sauf celle-là… dont l'absence me paraît absurde:

      while (pthread_mutex_destroy(&mtx) == EBUSY) {
        // mutex encore verrouillé ailleurs, on attend pour détruire 
      }
      

      La version C11 "mtx_destroy()" ne renvoie rien… dans ces conditions, le seul contournement c'est de se discipliner ou -super lourd- rajouter une variable de synchro. J'ai choisi l'option 1 pour pas gonfler, mais dommage quand même…

      (après mon opinion est que c'est bien de les avoir, même si le draft final est pauvre de fou)

      Il y a aucune fonction pour afficher les erreurs en chaine de caractère donc on peut pas faire un convivial perror ni strerror(errno).

      Assez d'accord ; c'est là que j'ai réalisé que les messages "perror()" étaient figés dans le runtime. J'avais toujours cru qu'on pouvait les surchager… tu me recommandes quoi, fournir ma propre fonction ?

      pourquoi des script shell pour compiler du code et pas un Makefile/ CMake

      Etant une pure démo, CMake (que j'utilise couramment) était trop lourd, hors de question.
      Un Makefile ça pourrait se faire, juste j'en ai pas écrit à la main depuis des plombes ! Je vais regarder…

      (au pire j'ajouterai des $CPPFLAGS/$CFLAGS dans le script -pour que l'utilisateur puisse facilement surcharger les commandes)

      • [^] # Re: Notes

        Posté par  (site web personnel) . Évalué à 8.

        gcc -M ou gcc -MM te génère ton makefile.

        "La première sécurité est la liberté"

        • [^] # Re: Notes

          Posté par  (site web personnel) . Évalué à 5.

          Alors ça… alors ça !!!

        • [^] # Re: Notes

          Posté par  (site web personnel) . Évalué à 3.

          Non ça génère des règles de dépendances en fonction des en-tête que tu as inclus. Donc si un fichier foo.c inclue foo.h alors foo.c sera recompilé en cas de modification de foo.h grâce à une règle que gcc -MMD/gcc -MM va générer sous la forme :

          foo.o: foo.c foo.h
          

          Cela est nécessaire pour garantir une recompilation du code source notamment pour assurer la compatibilité binaire. Sans ça, modifier une structure ou une fonction dans un entête ne provoquera pas la recompilation des fichiers dépendants, utilisant donc une version binaire non compatible.

          git is great because linus did it, mercurial is better because he didn't

          • [^] # Re: Notes

            Posté par  (site web personnel) . Évalué à 3.

            oui donc il génère un makefile fonctionnel. Je ne comprends pas ou tu veux en venir.

            "La première sécurité est la liberté"

            • [^] # Re: Notes

              Posté par  . Évalué à 2.

              Je suppose que le point est que ça ne génèrera pas un makefile qui gère les libs aussi souplement qu'un makefile à la main qui utilisera probablement pkg-config.
              Je ne fait que supposer, ici.

              Ma foi, je ne savais pas que c'était un format interprétable directement par make que ça crachais, je ne connaissais la fonctionnalité que grâce à la doc de ninja, je n'ai jamais eu la curiosité d'ouvrir ces fichiers. Merci de l'info.

              • [^] # Re: Notes

                Posté par  (site web personnel) . Évalué à 3.

                En fait les Makefiles bien écrits sont déjà auto-suffisant dès lors qu'on a pas trop besoin de portabilité et qu'on utilise gcc et clang, -MMD permet de générer des règles automatiques pour les entêtes. On peut donc avoir un Makefile qui recompile tous les fichiers y compris ceux avec dépendances indirectes.

                On peut par exemple avoir un Makefile tout à fait correct pour compiler un projet sans écrire aucune règle, cela est encore plus flagrant quand on a un nom d'exécutable du même nom du fichier.

                Avec GNU Make:

                SRCS = tetris.c board.c score.c
                OBJS = $(SRCS:.c=.o)
                DEPS = $(SRCS:.c=.d)
                
                override CPPFLAGS += -MMD
                
                .PHONY: all
                all: tetris
                
                tetris: $(OBJS)
                tetris: private LDFLAGS += -lncurses
                
                -include $(DEPS)
                
                .PHONY: clean
                clean:
                        rm -f tetris $(OBJS) $(DEPS)
                

                Démonstration:

                # tetris.c inclue common.h
                $ make
                cc  -MMD  -c -o tetris.o tetris.c
                cc  -MMD  -c -o board.o board.c
                cc  -MMD  -c -o score.o score.c
                cc -lncurses  tetris.o board.o score.o   -o tetris
                $ touch common.h
                $ make
                cc  -MMD  -c -o tetris.o tetris.c
                cc -lncurses  tetris.o board.o score.o   -o tetris
                

                git is great because linus did it, mercurial is better because he didn't

      • [^] # Re: Notes

        Posté par  (site web personnel) . Évalué à 5.

        Mise à jour comme promis :

        • license passée en LGPL-3.0 ou plus récente;
        • le hack avec _Bool() est en fait requis jusqu'à C23 exclu. #ifdeffé ;
        • j'avais un oubli dans les headers (c'est GCC en C23 qui me l'a signalé ;) ) ;
        • avant d'en arriver au Makefile, j'ai rendu les flags des scripts surchargeables à partir du shell.

        Par ailleurs pour tester tout ça, j'avais besoin d'une version méga-récente du compilo.
        J'avais peur de galérer, mais en fait j'ai trouvé ça facilement :
        - ici pour Debian/Ubuntu;
        - ici pour RHEL/Fedora.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.