rewind a écrit 3411 commentaires

  • # Conan

    Posté par  (Mastodon) . En réponse au journal La cochonnerie en boite que sont les systèmes de dépendances. Évalué à 6.

    je refuse catégoriquement d'intégrer Conan à notre base de code C++ juste parce que "les systèmes de dépendances, c'est le futur"

    Conan est écrit en Python, c'est pour ça que tu n'aimes pas :) Moi non plus j'aime pas Conan.

  • [^] # Re: Langage Carbon

    Posté par  (Mastodon) . En réponse au journal Google forke C++. Évalué à 7.

    Il n'y a pas de pointeur nul !

  • [^] # Re: C'est moi ou c'est idiot ?

    Posté par  (Mastodon) . En réponse au journal Google forke C++. Évalué à 5.

    Si le c++ expose les structures interne, c'est un peu moisi.

    It's not a bug, it's a feature! Le fait de n'exposer que des pointeurs force (quasiment) à faire des allocations dans le tas (via malloc typiquement). Exposer les structures internes, ça permet de ne pas faire d'allocation s'il n'y a pas besoin d'en faire. Par exemple, si je fais une classe Vec2 avec deux double: x et y, je n'ai pas envie d'allouer 128 bits à chaque fois que je crée un Vec2, j'ai envie de pouvoir les manipuler directement, sans allocation, de pouvoir faire des additions sans allocation (ce que C++ permet), etc. Et ça, tu ne peux le faire que si tu exposes les structures internes.

  • [^] # Re: C'est moi ou c'est idiot ?

    Posté par  (Mastodon) . En réponse au journal Google forke C++. Évalué à 8.

    Je me suis contenté de relater les drama au sein du comité de normalisation. Et là, c'est bien la question de l'ABI qui a été la goutte d'eau qui a fait déborder le vase de Google. Et quand je dis la question de l'ABI, c'est bien la question de la priorité qui est donné respectivement à la performance et au maintien de l'ABI au sein du comité de normalisation.

    Après, c'est juste l'aboutissement d'un long processus où Google n'a clairement pas la main sur sa destinée et c'est bien là le cœur du problème. Créer un nouveau langage est une solution pour eux. Et évidemment, ils ne vont pas faire un langage pourri, ils ont des contraintes industrielles qu'ils sont sans doute les seuls à avoir donc il faut que le langage soit top moumoute sur de nombreux points. Mais ce n'est que la conséquence de tout ce qu'il s'est passé avant. Ce que je veux dire, c'est qu'ils ne se sont pas levé un matin en se disant «tiens si on faisait un nouveau langage !», tout ce qu'il s'est passé ses dernières années dans le comité de normalisation C++ en est à l'origine.

  • [^] # Re: C'est moi ou c'est idiot ?

    Posté par  (Mastodon) . En réponse au journal Google forke C++. Évalué à 3.

    Tu as besoin de changer la représentation pour pouvoir arrêter le thread de manière anticipée. D'ailleurs, je viens d'aller voir dans la libstdc++ et std::jthread est implémenté avec un std::thread et un objet std::stop_source supplémentaire. Si on avait pu changer l'ABI, on aurait mis cet objet directement dans std::thread.

  • [^] # Re: C'est moi ou c'est idiot ?

    Posté par  (Mastodon) . En réponse au journal Google forke C++. Évalué à 7.

    Go n'a pas de problème d'ABI vu que Go compile tout en statique. Les problèmes d'ABI, c'est quand on fait des bibliothèques et que deux morceaux ont besoin de communiquer via un appel de fonction et doivent donc avoir la même représentation binaire des données qu'ils manipulent.

    Quant au langage de script, par définition, ils ne produisent pas de binaire (je schématise), donc pas de problèmes d'ABI non plus.

  • [^] # Re: C'est moi ou c'est idiot ?

    Posté par  (Mastodon) . En réponse au journal Google forke C++. Évalué à 8.

    Si si, ils en parlent. Au delà de l'ABI, c'est bien la performance qui est en jeu. La préservation de l'ABI n'est que le symptôme.

  • [^] # Re: L’anglais oui mais l’anglicisme ridicule non !

    Posté par  (Mastodon) . En réponse au sondage Mon rapport à l'anglais . Évalué à 10.

    Mon préféré dans ce genre, c'est l'événement commercial organisé par nos e-commerce français et qui s'appelle… «Les French Days» ! Quel beau titre pour célébrer la franchouillardise du bidule !

  • # C'est «has-been» l'anglois mec, faut se mettre au mandarin

    Posté par  (Mastodon) . En réponse au sondage Mon rapport à l'anglais . Évalué à 5.

    Vu que la population indienne va dépasser la population chinoise sous peu, il va falloir se mettre soit à l'hindi, soit au dialecte anglais pratiqué en Inde.

  • [^] # Re: C'est moi ou c'est idiot ?

    Posté par  (Mastodon) . En réponse au journal Google forke C++. Évalué à 10.

    Vu l'inertie du comité de normalisation, et vu qu'il y a déjà plein de gens en interne qui essaient tant bien que mal de faire pencher la balance du bon côté sans y arriver, je pense que ça ne va pas se passer. Il faudrait une révolution totale du processus de normalisation, en particulier sans doute sortir de l'ISO (avec les risques que ça peut occasionner). Personne n'y est prêt.

    La stratégie de Carbon est sans doute la bonne contrairement à tous les C++ killers passés : garder une compatibilité très forte avec C++ en permettant d'utiliser C++ directement dans Carbon. Ça permet une migration incrémentale sans aucun problème.

  • [^] # Re: Respect de l'ABI

    Posté par  (Mastodon) . En réponse au journal Google forke C++. Évalué à 8.

    Côté application, le concept même de DLL/SO est destiné à mourir: on n'a jamais trouvé et on ne trouvera sans doute jamais de bonne solution au dll hell, faire une ABI stable est atrocement difficile…

    Je ne dirais pas que c'est difficile. Il y a deux solutions actuellement : la première est celle que tu indiques à savoir tout compiler en statique. La seconde qui est encore beaucoup utilisée est de faire une API C en utilisant au maximum des structures dont l'implémentation est cachée. Avec ça, tu n'as aucun souci vu que l'ABI C est très stable, bien connue, assez simple à comprendre et qu'en prime, ça s'interface avec tous les langages de la Terre.

  • [^] # Re: Respect de l'ABI

    Posté par  (Mastodon) . En réponse au journal Google forke C++. Évalué à 8.

    Même si tu recompiles le monde entier, à un moment tu as quand même besoin de stabilité. D'ailleurs dans le noyau Linux, il y a aussi une garantie d'ABI stable sur certaines interfaces, ce n'est pas pour rien.

    Au moment du passage à C++11, GCC a été obligé de changer son implémentation de std::string pour pouvoir être conforme au standard. Ça a été long et douloureux ce petit changement. Notamment dans les distributions, on se retrouvait parfois à ne pas pouvoir compiler un logiciel parce que la bibliothèque qu'on utilisait avait été compilé avec l'ancien version de std::string. Il fallait jongler avec des options du compilateur, c'était pénible. Ça s'est résorbé avec le temps mais je pense que sur certains vieux systèmes où on met à jour la chaîne de compilation, on doit encore trouver ce genre de mésaventure. Et pourtant, ça fait 7 ans. Voir la page du manuel de GCC.

  • [^] # Re: C'est moi ou c'est idiot ?

    Posté par  (Mastodon) . En réponse au journal Google forke C++. Évalué à 8.

    «fausser les choses», tu y vas fort. Pour l'instant, on ne sait pas ce qu'est Carbon vu qu'il n'y a que des documents de design où il est écrit partout «TODO». Donc, je me suis bien gardé d'en dire davantage.

    Ils ne promettent pas d'être forcément beaucoup plus safe (notamment pas au niveau de Rust), seulement un petit peu. Ils ne promettent pas d'être plus performant, mais de faire au moins aussi bien que C++. Bref, pour l'instant, il n'y a que des promesses et pas vraiment de concret. Donc attendons de voir. D'après la roadmap, la version 1.0 est prévu pour 2024-2025.

  • [^] # Re: C'est moi ou c'est idiot ?

    Posté par  (Mastodon) . En réponse au journal Google forke C++. Évalué à 6.

    Non, ce n'est pas que de l'API. Si tu changes la représentation interne de ta classe, tu changes l'ABI. Et dans ce cas, tu es obligé, pour gérer la nouvelle fonctionnalité, de changer l'intérieur de ta classe.

    Si tu compiles une bibliothèque A avec l'ancien API et une bibliothèque B avec la nouvelle, elles ne pourront pas communiquer avec ce type (au mieux) ou ça va crasher sévèrement (au pire) parce que la représentation aura changé.

  • [^] # Re: C'est moi ou c'est idiot ?

    Posté par  (Mastodon) . En réponse au journal Google forke C++. Évalué à 10.

    Si le comité prend des décisions qui sont aussi discutables tout en refusant de les remettre en question ensuite, ça ne va pas poser de gros problèmes pour la pérennité du langage d'après toi ? Indépendamment des choix de google.

    Oui, ça pose des problèmes et ça en pose de plus en plus. Je vais citer la FAQ de Carbon : «C++'s process is oriented around standardization rather than design». Et je pense qu'ils ont entièrement raison. Pendant longtemps, l'usage, c'était de standardiser les expériences qui marchaient bien. Mais récemment deux exemples ont montré que ce n'est plus le cas.

    Premièrement il y a les modules. La proposition au départ était assez simple : se sortir du modèle d'inclusion de texte basique pour aller vers un vrai système de dépendances. L'idée était d'étendre les entêtes précompilés (qui existent depuis des années), les booster un peu et partir sur des bases saines. Avec comme effet de bord que ça pouvait accélérer la compilation. C'était aussi l'occasion de se défaire d'une partie du préprocesseur (but de long terme dans C++ depuis quasiment sa naissance). Il y a eu plusieurs propositions concurrentes (celle de Google et celle de MS), chacune à peu près implémentée (respectivement dans clang et MSVC) mais assez incompatible dans l'idée. Notamment la question du préprocesseur dans tout ça : fallait-il permettre d'exporter des macros ou pas ? ou d'autres questions tout aussi farfelues. Il y a eu d'âpres discussions pour arriver à un consensus et une proposition commune qui reprenaient les pires idées des deux autres propositions. Et au final, on aboutit à une infamie. Parce que personne n'arrive à l'implémenter (MSVC est le plus avancé sur le sujet mais d'après ceux qui l'utilisent, même des exemples simple provoque des crash du compilateur), GCC y travaille mais c'est compliqué, et clang est au point mort. Là, on a eu aucun retour d'expérience avant de standardiser un truc tout bancal. Mais comme le dit Julien Jorge, le comité était sous pression, il avait mis cet objectif dans C++20 donc il fallait que ça sorte dans C++20. Et du coup, ben voilà où on en est, on va sortir C++23 et on ne sait toujours pas utiliser les modules. Parce qu'au delà du compilateur, il faut du support au niveau des outils de build pour que ça fonctionne correctement, et donc (heureusement), ils sont en train de s'entendre pour avoir un format commun d'échange d'information mais c'est pas encore au point. Et puis à la fin, ça n'accélérera pas la compilation puisqu'avec la dépendances entre modules, il faut maintenant compiler les trucs les uns après les autres (ça revient à dérouler un DAG), alors qu'avec des fichiers source des des entêtes, on peut tout compiler en parallèle sans problème (make -j10). Bref, un crash industriel qui finira sans doute dans l'oubli.

    Deuxième exemple, le réseau. Moi, contrairement à Julien Jorge, je suis pour qu'il y ait plein de choses dans la bibliothèque standard. Mais en particulier, j'aimerais qu'il y ait plus de choses pour l'abstraction du système. Depuis C++11, on a eu la gestion du système de fichier (std::filesystem), la gestion des threads, la gestion des horloges. On va bientôt avoir la gestion des dates. Bref, tout ça pour moi, ça va dans le bon sens, c'est-à-dire qu'il n'y a rien de bien nouveau là dedans, c'est juste avoir une jolie interface commune à tous les systèmes. Mais il manque des morceaux et notamment le réseau. Or, en matière de réseau en C++, il y a une bibliothèque qui écrase le marché, c'est ASIO (qui est aussi présente dans Boost). Des milliers d'utilisateurs dans tout un tas de contexte, des années de maturation. Le candidat idéal pour une standardisation ! Et bien non, ça n'aura pas lieu. Pourquoi ? Parce que certains huluberlus trouvaient que le modèle de concurrence d'ASIO n'était pas top moumoute. Certains ont proposé de standardiser uniquement les trucs de bases genre socket pour TCP et UDP, résolution de nom, et basta. Mais non, le comité ne voulait pas parce que vous comprenez ma bonne dame, de nos jours toutes les applications réseaux ont besoin d'être parallèle pour gérer des millions de connexions à la secondes et qu'en plus, on veut du SSL par défaut. Donc, on a mis ASIO en attente pour gérer ce qui s'appelle «Executor» et qui est en fait l'introduction d'un modèle de concurrence. Sauf que là, pour le coup, je pense que ça n'a rien à foutre dans la bibliothèque standard un modèle de concurrence. Mais en prime, ils ont trouvé le moyen d'inventer un nouveau modèle (plutôt que de standardiser des trucs déjà existant), à peine testé, et surtout largement incompatible avec la manière dont ASIO fonctionne. Encore un crash industriel en perspective.

    On pourrait aussi parler d'une tentative d'introduire une partie audio. Le gars qui a fait la proposition disait en substance : «bon, toutes les API de base se ressemblent, ça consiste à envoyer des données régulièrement à un périphérique audio, il n'y a aucune innovation de ce côté donc on pourrait standardiser ça» (l'équivalent de l'API audio dans la SDL de base typiquement). Sauf que derrière, des spécialistes sont arrivés, ont flingué le truc en disant que ça ne gérait pas le temps réel, et bla bla. Fin de la discussion.

    Donc, on va continuer à réinventer des couches d'abstractions pour l'audio et le réseau parce que le comité ne se soucie pas de design d'API simple et efficace qui pourrait servir à 95% des gens mais se soucie de normaliser des trucs, peu importe ce que c'est. std::thread c'est pas fait pour ceux qui font du parallélisme de pointe (genre HPC) qui auront leurs propres solutions, mais on s'en fout parce que les 95% d'usages restant sont couverts. De même, std::vector, c'est un tableau dynamique de base qui sert 95% des usages, mais dans le jeu vidéo AAA où ils ont besoin d'avoir une maîtrise très fine (et aussi un peu de NIH), ils réimplémentent les tableaux dynamiques. De nos jours, le comité souhaitent que les trucs standardisés puissent être utilisé par les spécialistes et donc on monte des usines à gaz et au final, on se retrouve avec de la merde que personne ne peut utiliser parce que c'est trop compliqué (coucou les coroutines).

    Donc pour revenir à la question, oui ça pose problème à force. Parce que le problème orthogonal, c'est qu'on n'a pas de bon gestionnaire de paquets pour C++ (à l'instar d'un cargo pour Rust par exemple, et on pourrait d'ailleurs citer tous les autres langages en exemple), et donc on est encore condamné à bricoler suivant les systèmes (gestionnaire de paquets de la distrib dans Linux, avec les limites que ça peut avoir / vcpkg sous Windows) si on veut pouvoir tirer des fonctionnalités de base de bibliothèques externes à la bibliothèque standard.

    Personnellement, je suis resté à C++17, parce que c'était la fin du cycle commencé en C++11 et que c'est suffisamment mature. Pour la suite, j'attends de voir ce qu'il va se passer, que ce soit du côté de C++ ou du côté de Carbon. Rendez-vous dans quelques années.

  • [^] # Re: C'est moi ou c'est idiot ?

    Posté par  (Mastodon) . En réponse au journal Google forke C++. Évalué à 10.

    Cette histoire d'ABI, ça gonfle tout le monde. Par exemple, en C++20, il y a std::jthread qui apporte la possibilité d'arrêter le thread. Normalement, ça aurait dû être intégré dans std::thread mais comme on ne pète pas l'ABI, on a maintenant 2 types pour les threads.

    Et puis il y a aussi des problèmes plus profond. Par exemple, passer un std::unique_ptr en paramètre ne permet pas de le passer dans un registre alors que par défaut, un std::unique_ptr, c'est juste un pointeur dans une structure et que ça pourrait être passé via un registre.

    À la fin, ça fait plein de petits trucs qui font que Google en a eu marre. En particulier, ils ont proposé de mettre la performance en tête des priorité du comité de normalisation C++, ils ont été mis en minorité. Et puis il y a eu les propositions sur les modules, ils avaient fait une proposition très pragmatique, mais Microsoft a fait un peu du forcing et il y a eu conciliation qui a abouti à une horreur (d'ailleurs pas encore implémenté ni dans GCC, ni dans clang).

    Je pense qu'au delà des questions de performances, il y a surtout des questions d'orientation de C++ qui échappent totalement à Google, parce que l'ISO, c'est compliqué et que le comité C++ de l'ISO, c'est encore plus compliqué. Google a essayé d'influer autant que possible mais ça n'a pas bien marché. Et vu les enjeux financiers, ils ont intérêt à faire un truc de leur côté, ils en ont les moyens et sur le long terme, c'est gagnant pour eux.

  • # Éco-anxieux

    Posté par  (Mastodon) . En réponse au journal Le ministère du futur. Évalué à 8.

    Je t'invite à écouter ces quelques minutes de Frédéric Lordon qui vont peut-être transformer ton éco-anxiété : https://www.youtube.com/watch?v=CrKmxPkV2jY

  • [^] # Re: théorie des ensembles pas naives

    Posté par  (Mastodon) . En réponse au journal [Letlang] Et si on rédigeait la spec ?. Évalué à 4.

    ℝ n’est pas défini à partir de ℚ

    Si, ℝ est défini traditionnellement comme étant l'ensemble des limites des suites de Cauchy dans ℚ.

  • # Une grammaire ?

    Posté par  (Mastodon) . En réponse au journal [Letlang] Et si on rédigeait la spec ?. Évalué à 4.

    Je suis déçu, je pensais qu'on allait voir une grammaire du langage. Mais non, pas encore. Mais ça serait bien de définir une grammaire (ou du moins des morceaux de grammaires) pour qu'on se fasse une idée plus précise du langage autrement qu'avec des exemples. Une spécification, ça doit être assez formel et les grammaires sont le bon outil pour un langage (même si ça ne suffit).

  • [^] # Re: Il suffit parfois de quelques mois...

    Posté par  (Mastodon) . En réponse au journal une belle victoire de la démocratie. Évalué à 5.

    démocratie + européanisme + économie + social + libéralisme + écologie

    la carpe + le lapin + le beurre + la crémière + tout, son contraire, et même l'inverse

    Il y a de l'espoir, et on peut aussi se dire qu'en France on a perdu une occasion de faire pareil…

    Personnellement, j'appelle pas ça un espoir, mais un cauchemar !

  • # Pourquoi ?

    Posté par  (Mastodon) . En réponse au journal Comparatif d'outils d'analyse mémoire. Évalué à 4.

    Pourquoi ASan avec GCC et MSan avec Clang ? Les deux outils (ASan et MSan) ne visent pas du tout les mêmes types d'erreurs (et il me semble même qu'on peut les combiner). Il aurait fallu voir les deux outils avec les deux compilateurs (même si je pense que ça ne change pas grand chose, mais c'est mieux de le vérifier).

  • # Cas des élèves et étudiants

    Posté par  (Mastodon) . En réponse au journal Droits d'auteurs. Évalué à 4.

    Le cas des élèves est très simple : ils n'ont pas de droit sur les logiciels réalisés dans le cadre de leurs études. En fait, dans ce cas, on considère que ce qu'ils ont réalisé n'est pas venu de leur cerveau mais a été demandé par un supérieur (un prof) et qu'ils ont été encadré pour le faire, donc aucune inventivité propre.

    En revanche, dès qu'ils sont en stage, c'est tout le contraire, ils ont tous les droits sur ce qu'ils produisent dans l'entreprise. À moins que la convention de stage ne précise que les droits sont cédés à l'entreprise. Mais par défaut, ils gardent les droits.

  • [^] # Re: Survivor

    Posté par  (Mastodon) . En réponse au journal C, un âge remarquable. Évalué à 8.

    Boost n'a jamais prétendu être une bibliothèque header-only. Il n'y a pas que system qui a besoin d'une bibliothèque compilé (il y a aussi program_options, filesystem, regex, locale, serialization et sans doute d'autres).

    Ensuite, si, c'est modulaire, justement. Mais le problème vient du fait qu'il y a beaucoup de dépendances entre ces modules. En cherchant, on trouve sur le net le graphe de dépendances et c'est juste un enfer, ce qui fait que quand on tire une des bibliothèque de haut niveau, on tire la moitié des autres (mais après, c'est ce que promeut Moonz avec les crates de Rust).

    Chacun des deux systèmes (ultra-modulaire, ou largement monolithique) a ses avantages et ses inconvénients. Vu npm ou les crates ou boost, je ne suis pas sûr de vraiment préférer le système ultra-modulaire.

  • [^] # Re: Et pourtant les spécifications ne sont pas libre

    Posté par  (Mastodon) . En réponse au journal C, un âge remarquable. Évalué à 7.

    Et paradoxalement, la plupart des langages avec des spécifications libres n'ont qu'une seule implémentation, là où C et C++ en ont des dizaines.

    Concernant C++, la spécification finale n'est pas libre, mais la version bêta juste avant la spécification finale est disponible. Par exemple, pour C++20

  • [^] # Re: Survivor

    Posté par  (Mastodon) . En réponse au journal C, un âge remarquable. Évalué à 10.

    Autant tout recopier, c'est assez instructif :

    • Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring.
    • Rust needs to demonstrate that it can be used to create general-purpose libraries that are callable from all other programming languages.
    • Rust needs to demonstrate that it can produce object code that works on obscure embedded devices, including devices that lack an operating system.
    • Rust needs to pick up the necessary tooling that enables one to do 100% branch coverage testing of the compiled binaries.
    • Rust needs a mechanism to recover gracefully from OOM errors.
    • Rust needs to demonstrate that it can do the kinds of work that C does in SQLite without a significant speed penalty.