À propos de cppcon 2024

Notez que le contenu de cette page est en chantier, en particulier sur le plan du formatage, car je suis débordé. Je retravaillerai le tout dès que possible, promis.

Début du contenu technique

Je vais mettre le contenu technique dans des blocs les mettant comme celui-ci. Si vous ça ne tombe pas dans vos cordes, passez par-dessus.

Fin du contenu technique

Herb Sutter – Peering Forward – C++'s next decade

Herb Sutter : ce sont des temps excitants pour C++ alors que plusierus mécanismes importants sont sur le point de faire leur entrée dans le langage. Il parle de C++26 et de C++29. Il se dit d'avis que C++11 était le plus important changement dans le langage (même si C++20 est plus gros encore), mais indique que std::execution et des contrats, de même que les améliorations au type safety / memory safety et l'avènement de la réflexivité peuvent transformer le langage. Il ajoute la simplification du langage comme troisième changement majeur. Il rappelle que le Feature Freeze de C++26 est dans neuf mois à peine.

Herb Sutter commence en abordant la réflexivité, la définissant comme un programme qui peut se voir lui-même et s'auto-générer, donc un métaprogramme. La métaprogrammation en C++ n'est pas quelque chose de récent en C++, mais celle de C++ est statique, à coût nul lors de l'exécution. Il fait ensuite un historique de la métaprogrammation en C++ à partir de 1994 et du célèbre programme d'Erwin Unruhe qui ne compile mais mais génère des messages d'erreurs qui sont des nombres premiers, puis passant par Modern C++ Design d'Andrei Alexandrescu (un livre important), puis par constexpr (qui a tout changé, et a évolué de manière spectaculaire avec chaque version du langage), etc.

Herb Sutter parle ensuite des GPU et des Shaders, puis relate aussi l'historique de leur évolution à travers CUDA... Il y a un parallèle direct à faire avec l'évolution de constexpr. On veut C++ à la compilation. On veut C++ sur les GPU.

Herb Sutter parle ensuite de la réflexivité, à travers P2996, P3096, P3273, P3157 et P3294 (il y a un parallèle à faire ici aussi). Il montre un exemple qui utilise la réflexivité pour générer du code de traitement de paramètres passés à main(). Il mentionne quatre autres présentations orientées vers la réflexivité cette semaine.

Herb Sutter abord ensuite la question du memory safety. Il définit « Software Security » et « Software Safety » à partir de ISO/IEC 23643:2020, puis positionne « Programming Language Safety » comme garantissant les deux. Les quatre cibles à viser pour C++ sont selon lui type safety, bounds safety (il insiste sur celle-ci), initialization safety, lifetime safety. Selon lui, ce sont les quatre volets où la « compétition » fait mieux que nous. Il y a du progrès (utiliser std::span, réduire le comportement indéfini en introduisant le comportement erroné), et il parle aussi de Static Safety Rules Profile et de tests dynamiques de bornes. Il dit qu'on veut un meilleur C++, mais C++ va demeurer un outil de précision, un peu tranchant même si on réduit les risques d'accidents. Il aimerait qu'on progresse d'un modèle « watch out! » vers un modèle « opt out », où les trucs les plus dangereux sont disponibles sur demande seulement.

Herb Sutter mentionne les efforts de C pour réduire le comportement indéfini, mettant en relief les travaux de Robert C. Seacord. Ensuite, il discute du Erroneous Behavior qui sera avec nous dès C++26 (merci Thomas Köppe!). Il explique les effets bénéfiques de ce changement, et rappelle pourquoi l'initialisation à zéro n'est pas l'option que nous avons choisie. On aura un opt-out sous la forme de [[indeterminate]].

Herb Sutter met en relief que notre passage graduel à constexpr, consteval et cie a déjà réduite le comportement indéfini, car le comportement indéfini n'y est pas permis... On est déjà en voie de réussir! Il mentionne plusieurs présentations cette semaine (dont le Keynote de mercredi) qui discuteront de Safety.

Herb Sutter poursuit en abordant la question de la simplicité de la programmation en C++. Il parle de simplification par voir de généralisation, en permettant aux programmeuses et aux programmeurs de mieux exprimer leurs intentions. Parler plus du « quoi » que du « comment ». Il rappelle ses efforts de génération de code au cours de la dernière décennie et parle de ses expérimentations à travers son projet Cpp2. Il montre des exemples de code génératif qui se rapprochent de la syntaxe annoncée et compilent à l'aide du prototype de Daveed Vandevoorde sur godbolt (godbolt.org/z/fex55q50)

Herb Sutter montre ce qu'il est capable de synthétiser déjà par réflexivité, incluant des enum et des expressions régulières comme CTRE. Il montre que l'approche par rélexivité compile toutefois beaucoup plus rapidement que le CTRE « traditionnel ». Il rappelle que les fonctions constexpr compilent généralement (beaucoup) plus rapidement que l'équivalent par template metaprogramming. Autre avantage : tout se passe dans un compilateur C++, sans avoir besoin de recourir à ds outils tiers (il compare avec Qt ou COM ou WinRT). Il présente d'autres outils, par exemple podio chez CERN, qui peuvent bénéficier de réflexivité générative.

Herb Sutter invite Andrei Alexandrescu sur la scène pour discuter d'une expérimentation commune, une classe instrumented_vector<class...>. Il montre qu'il enrobe ainsi une classe (un std::vector encapsulé par sa classe) pour injecter des mécanismes comme de la tenue de statistiques d'appels de services. Andrei Alexandrescu pense que c'est le Killer App de la réflexitvité de C++. Ils présentent ensuite une grammaire suppléée (en langage D) sous une forme se rapprochant de EBNF, et génère un arbre syntaxique à la compilation. Andrei Alexandrescu montre qu'on peut faire un métaprogramme qui génère un compilateur C++...

Herb Sutter aborde la question de la fragmentation du langage en dialectes. Il pense que la réflexivité et le code génératif vont dominer la prochaine décennie de C++, et qu'on va en abuser, mais que c'est un peu comme l'avènement de la surcharge d'opérateurs à une autre époque. On compare avec le code généré par de l'IA générative.

Herb Sutter dit que toute l'information dans le code source doit être « réflexible », incluant les caractères d'espacement et les qualifications d'accès. Il ajoute que tout code source doit être « générable ». Par expérience, il dit qu'il faut être capable de contrôler la présentation du code généré, pour faciliter la compréhension et le débogage. Il faut aussi être capable de générer tout format de fichier, incluant du texte et des binaires.

Herb Sutter aborde la question de comment le Safety contribue à la simplicité. Il insiste sur le fait que réduire les risques d'erreurs simplifie la vie des programmeuses et des prgorammeurs. Il aborde la question de l'initialisation des variables, qui est un problème complexe et multi-facettes. Il milite pour une approche « initialize before first use » sur tous les chemins. Il mentionne l'approche choisie par Cpp2 (qui diffère un peu de celle de C++, car dans son projet le constructeur est appelé à la première initialisation et la définition se limite à réserver l'espace pour la sécurité).

Herb Sutter propose ensuite l'injection de bounds check au point d'appel pour tous les conteneurs contigus en mémoire et auxquels std::size() s'applique (du moins pour les profils en vertu desquels cela fait du sens), avec un « opt-out » heureusement. Il termine avec un rappel de l'importance de tout cela à ses yeux.

Dietmar Kühl – Creating a Sender/Receiver HTTP Server

Dietmar Kühl présente le problème qu'il aborde aujourd'hui et situe ses travaux dans le contexte du Beman Project (cool!), envisageant std::execution pour C++26 et Networking pour C++29. Il procède ensuite par du Live Coding (re-cool!). Note personnelle : je vais vouloir lire son net29.

Je ne prendrai pas tout en note, préférant regarder le code qu'il écrit. Dietmar est un excellent programmeur et son code est très élégant. Il mentionne que pour une coroutine acceptant une lambda (en général, pas juste dans son exemple), il est préférable de se baser sur les paramètres que sur le bloc de capture. Il dit préférer std::invoke() à une IIFE car ça lui semble plus explicite. Il y a quelques accrochages (nervosité et codage « live ») mais c'est très intéressant. En particulier, il est expert de la manipulation des flux, alors son code en ce sens est très propre.

La présentation met en valeur des coroutines et les opérations asynchrones. Il montre que la gestion des « timeouts » est intégrée au modèle (ça rappelle le modèle applqiué par Go). Le code complet est élégant, mais pas simple. Son traitement d'erreur repose sur un variant de tous les codes d'erreurs possibles... Il a des mécanismes pour transformer un code de retour en erreur... ou en std::expected.

Q : j'ai vu le recours à des scope. Comment cela interagit-il avec les coroutines?

Dietmar Kühl explique la mécanique en détail.

Q : y a-t-il eu des progrès pour ce qui est de coroutines avec allocateurs?

Dietmar Kühl explique comment y arriver (il dit l'avoir fait).

Q : pourquoi utiliser variant pour les exceptions?

Dietmar Kühl : pour retourner une valeur parmi plusieurs sans avoir recours à de l'allocation

Jeff Garland : le Beman Project est très cool. As-tu des autocollants?

Dietmar Kühl : ouais!

Q : comment faire un test unitaire de tout ca?

Dietmar Kühl : oui, mais je n'en ai écrit qu'un seul.

Q : il y a beaucoup de trucs là-dedans qu'on aimerait avoir. Ce sera dans le Beman Project?

Dietmar Kühl : le Beman Project est un projet bénévole, qui commence à peine. Vous pouvez contribuer et participer (Jeff Garland : vous pouvez nous aider en faisant des revues de code aussi)

Jon Kalb – Bitcoin: History and Use Cases

Jon Kalb explique d'office que ce ne sera pas une présentation technique, mais plus une présentation historique et contextuelle. Il veut raconter l'origine du Bitcoin, puis les cas d'utilisation pour cette technologie (il en a trois en tête, dont un qu'on ne soupçponnera pas apparemment).

Jon Kalb commence en relatant le Whitepaper d'origine, par Satoshi, qui a été publié aux Cypherpunks. Il cite Eric Hughes, qui a écrit leur manifeste en 1993, et nous le présente (il est dans la salle). Semble que Eric Hughes ne soit pas un fan du Bitcoin, ce qui rendra la discussion intéressante! Il cite ensuite Steven Levy (auteur du livre Hackers) et de la « révolution Cypherpunk » (PGP et ce genre de truc), puis The Genesis Book à propos des gens et des projets qui ont inspiré l'avènement du Bitcoin. Certaines personnes dans la salle sotn de ce mouvement, et relatent que la NSA les suivait bel et bien à l'époque.

Jon Kalb indique que les premières tentatives pour produire un modèle de monnaie électronique ont été des échecs, du moins jusqu'à ce que Finney en arrive à produire le Bitcoin en soi.

Jon Kalb parle de problèmes qu'on souhaite résoudre par cryptographie : envoyer un message, signer un message, résoudre le pourriel, et dépenser (send / sign / spam / spend) :

• Pour l'envoi, l'idée est d'envoyer un message tout en empêchant qu'un tiers non-autorisé interceptant le message n'en comprenne le contenu. Il parle de chiffrement à clé publique.
• La limite est que le destinataire ne peut pas savoir si l'émetteur est la personne qu'il dit être. Pour ceci, il faut signer le message : créer une signature numérique vérifiable par le destinataire, et ce à l'aide de sa clé publique (une question sur la possibilité de faire plusieurs modifications et de contourner la protection est posée; Eric Hughes se lève et explique ce qu'il nomme le « Avalanche Property » de ces fonctions, un truc qui rend extrêmement improbable ce type d'attaque).

Jon Kalb explique que combiner ces deux propriétés permet essentiellement une communication sécurisée entre deux tiers. Évidemment, on ne cache pas ce faisant le fait qu'on communique, mais on peut utiliser des techniques de stéganographie (par exemple) pour obscurcir cela.

• Pour le pourriel, l'idée était de décourager l'envoi massif de message non-sollicités, une idée qui (tristement) n'a pas eu le succès escompté. La solution technique existe (il réfère au « Proof of Work » d'Adam Back, qui introduit un coût à l'envoi d'un message, représenté par une preuve d'effort : le coût est trivial pour un seul message, mais considérable pour un envoi de masse). L'idée : un message a des métadonnées (un destinataire, un sujet, une date, un corps, etc.) : on en fait un hash par un moyen qui demande du calcul, par exemple avec SHA2-256 de la NSA. Eric Hughes confirme que la NSA est très bonne pour briser des codes et pour concevoir des algorithmes de chiffrement de qualité. Sherry Sontag et Eric Hughes échangent sur le sujet, c'est divertissant. Aux métadonnées on ajoute un nonce avant de calculer le hash. On fait ensuite en sorte que les serveurs de courriel ne relaient que les messages qui débutent par un certain préfixe (un certain nombre de zéros), ce qui impose en moyenne de recalculer un nonce... parfois plusieurs fois... Notez qu'un Proof of Work demande un effort à produire, mais est trivial à vérifier. C'est l'équivalent moral d'un puzzle. L'une des idées de Satoshi est de permettre l'ajustement dynamique de l'effort associé au Proof of Work.
• Pour la dépense, le but est de pouvoir transférer une valeur à un tiers sans quelque interférence que ce soit (frontières, tiers hostiles, accès à un compte bancaire, etc.), incluant quelque modification que ce soit. Les problèmes initiaux étaient : (a) une double dépense (si on peut envoyer de l'argent à volonté, l'argent perd sa valeur), or dans le monde numérique on ne peut pas empêcher la production de copies parfaites (une solution est un tiers de confiance, mais ça devient un Single Point of Failure), et (b) le problème des généraux byzantins (construire un système fiable en présence de composants qui ne le sont pas).

Jon Kalb explique la solution de Satoshi, qui résout ces deux problèmes avec (a) des clés privées et publiques, (b) du hashage SHA2-256, (c) du « Proof of Work » et (d) des Merkle Trees. Par les Merkle trees, on prend les hash de transactions pour faire des hash de hashes, ce qui rend le déchiffrement progressivement plus ardu. Ceux qui contribuent à l'accroissement de la chaîne ont un « bonbon » en échange, soit... des bitcoin. En moyenne, produire un bloc pour la chaîne prend beaucoup de travail et sert à titre de « Proof of Work ». Il explique comment un choisit entre deux mineurs pour un même bloc (le bloc qui a le plus de travail de fait gagne, vraiment).

Jon Kalb explique que le système est honnête par voie de rareté : il y a un plafond au nombre de Bitcoins (21 millions), et même si quelqu'un pourrait vouloir en créer plus, les autres vont les refuser (ça dévaluerait leurs propre Bitcoins).

Jon Kalb montre que la valeur des Bitcoins fluctue, mais monte de manière logarithmique avec le temps. Il se dit ensuite d'avis que le principal cas d'utilisation pour la technologie est la production monnaie indigène d'Internet.

Q : il y a des technologies alternatives. Que doit-on en comprendre?

Jon Kalb : que certains veulent vous faire croire qu'ils peuvent faire aussi bien! De toute manière, il y a tellement d'usagers et de noeuds dans ce monde qu'il faudrait un effort considérable pour les battre.

Q : et si j'ai 1000 bitcoins mais on détruit ma clé privée... j'ai tout perdu?

Jon Kalb : oui. Techniquement, tu viens de contribuer un peu d'argent au reste du monde.

Kevin Carpenter – Back to Basics: Almost Always Vector?

Kevin Carpenter explique qu'il souhaite convaincre les gens présents que, en particulier pour les débutants, vector est le choix à privilégier au moins 80% du temps.. Il propose N0083 qui semble être la proposition originale d'un tableau dynamique (on remonte à 1992, avant que la STL n'arrive car... ça a tout changé), cool! À l'époque, les auteurs utilisaient leur classe G_DynArray<T> comme classe de base pour d'autres conteneurs.

Kevin Carpenter nous explique qu'il utilise beaucoup at()... Eh ben...  (note : faut que je lui parle du terme « type of iterator »)

(j'ai dû quitter à 15 minutes de la fin pour me préparer un peu)

Patrice Roy – Many ways to kill an Orc (or a Hero)

J'ai fait de mon mieux 🙂 Je me suis dépêché et j'ai essayé de rendre ça dynamique (j'avais plus de 200 diapos pour une heure!), mais je regardais le mauvais « cadran » pour l'heure alors je pensais qu'il ne restait que deux minutes alors qu'il en restait presque huit. Pauvre public! En plus, il y avait des élèves du secondaire qui programment en C++ avec leur prof dans la salle... Mais tout ce beau monde est resté jusqu'à la fin, et j'ai eu quelques questions et plusieurs bons mots une fois le tout terminé.

Jamie Pond – Composing Ancient Mathematical Knowledge Into Powerful Bit-fiddling Techniques

Jamie Pond est enthousiaste. Il se dit heureux d'être parmi nous. Il discutera d'intuitions provenant d'algorithmes de multiplication du temps des égyptiens permettant de synthétiser des opérations parallèles particulièrement efficaces. Il se présente, provenant du monde du logiciel audio. Il se dit inspiré par le livre d'Alexander Stepanov et Daniel E. Rose nommé From Mathematics to Generic Programming (un excellent livre en effet). L'associativité est au coeur des techniques dont il compte nous parler. Il explique que CUDA, par exemple, n'a pas de primitive pour l'exponentiation des entiers, mais en a pour les double.

Jamie Pond rappelle le sens des termes commutativité et associativité. Il dit que la capacité de grouper (mais pas de « commuter ») les opérandes sont ce qui lui permet de transformer un algorithme O(n) en algo O(n log_n). Il rappelle un algorithme de multiplication « égyptien » (rien de compliqué, mais vous regarderez les diapos). Il montre ensuite les étapes intermédiaires pour montrer que cet algorithme génère beaucoup moins de résultats intermédiaires que ceux auxquels nous sommes habitués.

Jamie Pond passe ensuite à une implémentation C++ du même algorithme, qu'il décrit comme « régressive ». Il parle ensuite d'inverser l'ordre dans lequel les bits sont traités, et nomme cette technique « Associative iteration ». Il montre l'algorithme.

Jamie Pond parle ensuite de généraliser la formulation régressive. Il rappelle que la multiplication des entiers peut être représentée par une répétition d'additions.

Jamie Pond aborde ensuite sa bibliothèque SWAR, qui est du SIMD logiciel plutôt que matériel (en jouant sur les bits et en interprétant les résultats différemment, le tout em faisant attention aux débordements). On peut voir https://github.com/thecppzoo/zoo pour les sources

Jamie Pond présente la multiplication SWAR et l'association itérative, puis montre que la généralisation lui permet d'implémenter l'exponentiation SWAR (il montre au passage que le compilateur fait des miracles avec le code machine, via godbolt). Effectivement, le code généré est d'une qualité stupéfiante.

Jamie Pond se dit d'avis que l'association itérative est plus générale que SWAR... en fait, aussi générale que les monoïdes. Cette technique permet d'implémenter des primitives qui manquent à une plateforme matérielle.

(c'était une présentation courte, moins de 40 minutes)

Eric Hugues signale que la technique peut être étendue à des lieux insoupçonnés, par exemple de la multiplication de matrices (Jamie Pond est content!)

Jody Haggins demande s'il est possible d'étendre la technique à la substraction et à la division. Jamie Pond pense que oui.

Eric Hugues revient et se dit d'avis qu'on peut faire du FFT parce que les bases de fused multiply add sont là; idem pour de la convolution sur des tableaux de pixels. Jamie Pond est du même avis (il dit vouloir attaquerle cas des FFT sous peu).

Michael Wong – Security Panel

Michael Wong anime ce soir. Les panélistes sont Herb Sutter, Andreas Weis, Gabriel Dos Reis, Timur Doumler et Lisa Lippincott.

Michael Wong présente ce panel comme le plus important de tous, et qu'on y insistera sur ce que le comité a fait cette année pour les enjeux de Safety et de Security. Chaque panéliste se présente et donne son pedigree

Andreas Weis dit qu'il travaille dans le monde des automobiles intelligentes et oeuvre sur MISRA C++.

Gabriel Dos Reis travaille chez Microsoft et parle de l'importance de ces enjeux pour son entreprise. Il représente le NB de la France sur WG21, et travaille avec Bjarne Stroustrup sur les Profiles.

Lisa Lippincott travaille beaucoup sur le Program Correctness et s'est impliquée dans les contrats.

Herb Sutter écrit sur ces sujets et a donné plusieurs conférences à propos d'eux. Il oeuvre sur les Core Guidelines et essaie de faire adopter les Profiles. Il dit avoir hâte de voir les contrats, mais ne pense pas qu'ils soient un enjeu de Programming Safety (intéressant)

Timur Doumler est co-Chair de SG21, s'intéresse à SG23 et travaille sur les contrats. Il dit ne pas être en désaccord avec Herb Sutter 🙂

Michael Wong ouvre la porte aux questions du public.

Q : en quoi les contrats de C++ touchent-ils les enjeux de Safety et de Security? En quoi sont-ils insuffisants?

Timur Doumler : demande à plusieurs personnes et tu auras plusieurs réponses. Selon moi, les contrats sont surtout un enjeu de Correctness, une manière d'éliminer les bogues d'un programme, mais ils ne changent pas la sémantique d'un programme ou du langage

Gabriel Dos Reis : je suis impliqué dans les contrats depuis 2014, et nous avons eu plusieurs itérations. Ce que nous avons en ce moment est mieux que ce qui a précédé, mais par petits pas. J'essaie de pousser le groupe à traiter le Safety sur la base de principes. J'ai dû expliquer au comité pourquoi Microsoft ne supporte pas la version des contrats qui était discutée lors de la rencontre de Tokyo en 2024. On ne semble pas faire ce qu'on devrait faire. Les contrats ne changent pas beaucoup le langage, mais ils devraient le faire. Je pense qu'on est en train de manquer une belle opportunité. Les contrats ne sont utiles que si on écrit du code correct, selon certains, mais c'est un angle incorrect

Herb Sutter : je veux que les contrats réussissent, ils sont utiles, mais le Safety est un enjeu de garanties. Les langages que certains veulent préférer à C++ n'ont pas de contrats; le delta est un ensemble de règles de langages qui offrent des garanties. Les contrats ne sont utiles que si on les écrit; ils n'offrent pas de garanties à l'ensemble du programme

Lisa Lippincott : il y a des perspectives différentes sur le sujet, et la mienne est différente de celles de Gabriel Dos Reis et de Herb Sutter. Sur un chantier de construction, mettre un casque accroît notre sécurité, mais n'assure pas notre sécurité. Les contrats contribuent à la sécurité.

Q : Sean Baxter a publié un papier sur l'ajout d'un Borrow Checker à C++. Quelle est votre opinion sur le sujet?

Andreas Weis : ce que Sean Baxter fait est très impressionant et démontre qu'on peut adapter le Borrow Checker de Rust à C++. Cela balise ce qu'il y a à faire, et offre un modèle très fort. Il montre aussi ce que ça nous coûterait de l'implémenter, incluant une sémantique de mouvement différente, une toute nouvelle bibliothèque standard, ... En fait, on en arrive à quelque chose qui n'est plus vraiment C++. C'est peut-être ce qu'il faut, mais il faut être conscient de ces coûts

Gabriel Dos Reis : on ne peut pas jeter aux ordures des milliards de lignes de code... Ce que Rust a fait est fantastique, mais ce n'est pas C++. Que ferions-nous avec tout le code existant?

Lisa Lippincott : j'ai lu la proposition et je la trouve très intéressante. C'est un changement radical au langage existant, et ce serait un gros morceau à avaler. Je me demande si le problème est que le modèle de Rust est pris trop littéralement, et si on pourrait l'adapter à notre réalité. J'ai des idées...

Timur Doumler : faut décider quel est le degré de Memory Safety dont nous avons besoin en C++.

Gabriel Dos Reis : un langage de programmation système parle au matériel, et dans ces moments certains trucs étranges peuvent se produire. Peu importe ce qu'on fait, il faut un peu de latitude. On peut écrire des programmes Memory Safe en C++, mais la question est de savoir quel niveau d'habiletés est nécessaire pour y arriver

John Lakos : nous avons travaillé avec Sean Baxter et plusieurs de ses idées sont fantastiques. L'ensemble est peut-être trop, mais certains aspects peuvent être intégrés à C++ sans prendre l'ensemble (par exemple la relocalisabilité triviale). Selon moi, cela dit, les contrats apportent beaucoup plus que ce qu'on laissait entendre ce soir. Je demande à Gabriel Dos Reis si on devrait cesser d'écrire des tests unitaires car on fait parfois des erreurs ce faisant

Gabriel Dos Reis : bien sûr. Il explique le problème d'écrire un test qui donne dans le comportement indéfini, par accident, et de le voir se faire supprimer par un  compilateur zélé (il prétend aussi que des contrats dans la bibliothèque standard seraient chouettes, mais que tout le monde semble contre ça)

Herb Sutter : Sean Baxter est un génie, mais faut en arriver à quelque chose que le public acceptera (il rappelle l'avènement de la sémantique de mouvement avec C++11). Rust est plus sécuritaire que C# et Java pour le Thread-Safety, mais l'est moins pour d'autres trucs; il y a plus de code unsafe en Rust qu'en Java ou en C#

Gabriel Dos Reis : on devrait tous regarder Rust car il y a beaucoup à apprendre

Michael Wong : si on fait ça, ce ne sera plus C++

Q : je suis pour la Compile-Time Safety, mais il y a des coûts et il faut se souvenir que l'on supporte des systèmes embarqués...

Lisa Lippincott : je crois encore au principe de You Shall Not Leave Room for a Lower-Level Language...

Gabriel Dos Reis : il y a des moments où il faut interpréter les bits... Il faut aussi trouver un équilibre entre la sécurité et la vitesse. Selon moi, il nous faut une amélioration dans les outils

Herb Sutter : il nous faut un opt-out...

Andreas Weis : nos usagers veulenent le maximum, le plus de contrôle, le plus de vitesse...

Lisa Lippincott : le langage peut écrire à l'écriture de programmes corrects

Q : si on ne peut pas atteindre plus de 99% de Safety, quelle est la valeur de cette atteinte?

Michael Wong : peut-on atteindre le 100%?

Herb Sutter : aucun langage commercial ne le peut...

Ben Deane – Another Grab-bag of Oddments

Ben Deane commence en indiquant qu'il aime jouer, et cite Isaac Asimov qui préfère « It's funny... » à « Euréka! ». Il présente des accès à des tableaux multidimensionnels, et indique que la « fluent syntax » de la programmation orientée objet. Il montre une réelle application syntaxique de i[tab] une lambda pour éviter le problème de deux '[' consécutifs étant limités aux annotations :

int a[5]{...};
a[ [] { return 2; } ]; // illégal à cause de [ [
[]{ return 2; }[a]; // Ok

Ben Deane examine ensuite les nombreuses syntaxes possibles pour des fonctions en C++ : f(a,b,c), f<a,b,c>, f[a,b,c] depuis C++23, car on peut maintenant faire auto operator()(auto...){} et auto operator[](auto...){} alors les crochets sont conceptuellement équivalents aux appels de fonctions si on regarde de manière assez oblique. Il présente un cas d'utilisation en positionnant [] comme un opérateur de lookup

Ben Deane demande combien de syntaxes de lambdas nous avons. Il trouve qu'on en manque :) Comment détecter une lambda? Il écrit un trait is_lambda<T> (c'est divertissant... et pervers)

Ben Deane montre ensuite un truc qui fait l'équivalent d'une surcharge sur la base d'un paramètre étant un type ou une valeur. Son truc passe par une macro dans laquelle il injecte un if constexpr. Détecter si un paramètre est un type ou une valeur est difficile. Il crée un type from_any qui est constructible à partir de n'importe quoi.

Eduardo Madrid – Relocation: Blazing Fast Save And Restore, Then More!

Eduardo Madrid dit qu'il aurait pu nommer sa présentation « the opposite of pointer chasing ». Il reconnaît le besoin de polymorphisme dynamique et celui de permettre à un objet de référer à un autre. Il dit que son approche rejoindra celles du Data Orientation. Son but est de placer les données à l'endroit où les « performances » seront les meilleures (je regarde sa description de Data Orientation et ça ressemble beauoup à du SoA, en essayan de réduire les indirections polymorphiques au minimum)

Eduardo Madrid présente sa méthodologie de décompostion, qui tient compte d'enjeux d'alignement et de nullabilité. Il nomme les indices de son SoA des « handles », et montre des classes qui font le pont entreles données déstructurées et une forme « objet ».

(certaines questions de la salle montrent un désaccord de principe entre Eduardo Madrid et des membres de l'audience, mais il gère la situation avec élégance)

Eduardo Madrid aborde enfin l'enjeu de la relocalisation en insistant sur l'importance d'avoir des indices stables. C'est aussi vrai quand on implémente un redimensionnement de tableau dynamique, pour les mêmes raisons. Il recommande d'ajouter une strate d'indirection pour que la relocalisation soit transparente. Il cite Björn Fahller à quelques reprises (il est chouette, l'ami Björn!). Il ajoute que la capacité de relocaliser permet aussi de réduire la fragmentation de la mémoire. Ça peut aussi aider à combattre les cas de faux-partage.

Eduardo Madrid insiste sur le fait qu'une meilleure localité des données, en temps et en espace est essentielle pour obtenur un programme efficace.

Khalil Estell – C++ Exceptions for Smaller Firmware

Khalil Estell se présente, et explique son pedigree. Il vient du monde des microcontrôleurs, alors il décrit les limites, restrictions et réalités de ce petit monde. L'immense majorité de ces appareils ont moins de 100KB de mémoire alors l'allocation dynamique... on va repasser. Sauf peut-être à l'initialisation... Parfois. Il mentionne la Embedded Template Library (ETL), et std::inplace_vector qui vient d'être adopté dans la bibliothèque standard.

Khalil Estell dit que les systèmes embarqués évitent les exceptions entre autres parce que ça prend de la mémoire, que ça alloue dynamiquement, que ça impose RTTI, etc. ll passe ensuite pas un exemple concret d'une classe modélisant une Output Pin avec un service de type void, mais pour lequel des erreurs étaient possibles (ce qu'il a su ultérieurement). Évidemment, ça a fini par causer des ennuis... Il a fini par remplacer void par expected<void,erreur>, mais ses étudiant(e)s les faisaient disparaître avec des (void)... Hé la la...

Khalil Estell dit que certain(e)s de ses étudiant(e)s demandaient « pourquoi » les exceptions avaient la réputation d'être lentes, lourdes et indéterministes. Il explique sa démarche d'exploration. Son premier essai était... catastrophique! Mais il montre comment il a progressé dans sa démarche... et il est très divertissant. Entre autres, il déactive RTTI et, en pratique, les exceptions fonctionnent encore (il en reste des bribes, mais elles sont minimalistes)

Khalil Estell note, et c'est intéressant, qu'il a remarqué que la taille des binaires de gros projets devenait souvent plus petite avec les exceptions, mais celle est petits projets devenait plus grande. Et il me cite, tiens donc, photo en gros plan à l'appui! C'est drôle, ça! Il décrit le modèle mathématique par lequel il a testé ses hypothèses. Il rejoint ma vision à l'effet qu'on a plus de génération et de propagation d'erreurs dans un programme que l'on a de gestion d'erreurs (et de beaucoup!)

Khalil Estell présente trois catégories de fonctions (feuilles, celles sur le chemin d'une propagation, celles qui les gèrent), Ensuite, il explique les conventions en vigueur sur ARM pour les registres et les conventions d'appel. On a droit à une très claire explication de la mécanique d'une levée d'exception, à bas niveau. Entre autres, on voit qu'une espèce de photo des registres du CPU fait partie de l'en-tête (des métadonnées) qui accompagnent l'exception dans son voyage. On va en profondeur dans les instructions machines et les représentations des données qui participent au processus. Il mentionne le LSDA (Language-Specific Data Area), qui sert aux programmes qui souhaitent attraper une exception levée dans un autre langage. Le catch(...) est un pointeur nul dans la table des types possibles à attraper, en pratique. Les comparaisons des types sont efficaces (on utilise des pointeurs du RTTI minimaliste)

Khalil Estell explique par la suite les coûts en espace du recours aux exceptions, s'il n'y a pas de destructeurs, s'il y en a, s'il y a plusieurs blocs catch, etc. Il compare ensuite avec les coûts en espace de l'équivalent fait avec des codes d'erreurs, par exemple std::expected, puis bool. Il compare avec ce que Rust fait... ce qui équivaut à std::expected en pratique

Khalil Estell parle ensuite de Distributed Error Handling (les codes d'erreurs vont là pour lui) et de Centralized Error Handling (les exceptions vont ici pour lui). Il fait des démonstrations avec des erreurs dans des appels complexes (p. ex. : a() + b() + c() + d() + e()). Il prend quelques cas concrets. Son approche est intéressante.

Khalil Estell met de l'avant que le code du mécanisme des exceptions n'est payé qu'une seule fois, et montre comment le recours aux exceptions peut réduire la taille des programmes. Il propose des optimisations possibles dans le code généré. Cool!

Khalil Estell conclut que les exceptions en C++ sont une forme de compression de code. Il dit que sa prochaine présentation expliquera comment réduire le coût de la mécanique des exceptions par 88%... On est dûs pour mettre nos implémentations à jour (il dit que peu de gens ont travaillé à implémenter la mécanique des exceptions, du moins avec gcc, et ça fait plusieurs années). Son autre présentation sera à propos d'un « exception insights tool » pour aider à comprendre ce que les fonctions peuvent lever. Je vais devoir mettre à jour mon matériel sur les exceptions dans IFT611, IFT729 et INF749 🙂

Khalil Estell offre quelques remerciements, et mentionne P1947 qui est le texte séminal sur les exceptions. Beau boulot!

Q : quand on parle de la copie des objets modélisant des exceptions, que fait-on si le tampon statique remplaçant l'allocation dynamique déborde?

Khalil Estell : mon outil servira un peu à ça, soit assurer le plafond d'espace requis

Q : respect! Je fais de la robotique et de l'aérospatiale. J'ai l'obligation d'offrir un Code Coverage de 100%. Comment puis-je faire cela avec des exceptions?

Khalil Estell : c'est un autre atout de mon projet Exception Insights, lister les chemins menant à des exceptions non-attrapées

Q : vas-tu implémenter tout ça dans gcc?

Khalil Estell : clang d'abord, gcc ensuite

Q : ton outil voit-il à travers les frontières des bibliothèques chargées dynamiquement?

Khalil Estell : on a des idées, des plans, mais ça reste à faire

Q : as-tu regardé x86, x64 et Windows

Khalil Estell : il va me falloir des ressources, et il faudra que Microsoft me contacte

Jason Turner – Case for Non-Moveable Types

Jason Turner liste les fonctions membres spéciales de C++ et les explique une à une. Il dit essentiellement les mêmes trucs que moi en classe, c'est toujours drôle à entendre.

Jason Turner s'amuse avec la vie des objets pour des objets dont la Sainte-Trinité est mal foutue. Il fait ensuite mimer une durée de vie par trois personnes dans la salle (c'est exactement le genre de truc que je fais) avec un constructeur de copie et une affectation de copie.

Jason Turner aborde ensuite la « règle de zéro / règle de cinq ». Il dit que quand il doit écrire un destructeur, il utilise =delete sur les opérations de copie et les opérations de mouvement à moins d'avoir une bonne raison de faire autrement.

Jason Turner rappelle qu'un objet « moved-from » doit être dans un état « valide mais non-spécifié ». Quelqu'un demande un exemple qui briserait ceci (il en aurait eu un s'il avait été dans ma classe la fin de semaine dernière 🙂). Il montre un cas d'un type où il fait =default sur les opérations de mouvement et fait delete sur un pointeur dans un destructeur (pas une bonne idée...). Il offre ensuite un exemple « complet », mais un membre de l'audience fait remarquer que dans son code on aura du comportement indéfini avec a = std::move(a);.

Jason Turner en arrive à un exemple plus intéressant avec de la mémoire partagée représentée par un fichier (un int). Son affectation de mouvement ferme le fichier (ouille!), ce que certains membres de l'audience voient (bravo!). Certains mentionnent (re-bravo!) qu'on n'a pas défini ce qu'on entend comme « valide » dans le code présenté. Le coeur du propos est qu'il ne faut pas permettre de mettre un objet dans un état invalide; son type n'offre pas d'alternative à celle d'un état invalide post-mouvement, et dans un tel cas, mieux vaut probablement ne pas exposer d'opérations de mouvement. Il liste quelques abstractions qui tombent selon lui dans ce créneau.

Andreas Fertig – Fast and small C++: When efficiency matters

Andreas Fertig se présente et explique que son nom de famille, étymologiquement, signifie « terminé, complété ». Il est l'individu derrière C++ Insights, un très chouette outil dont je me sers dans mes cours. Il dit qu'il n'est pas un auteur de bibliothèque standard, ce qui peut être un problème mais a aussi l'avantage que son code risque d'être plus lisible 🙂

Andreas Fertig aborde d'abord la question des Compressed Pairs, une technique pour récupérer de l'espace, et donne l'exemple d'un unique_ptr<T,D> où D est un Custom Deleter (il y a quelques petites inexactitudes; je vais lui écrire tantôt). Il explique EBO pour soutenir son argumentaire. Il utilise un Custom Deleter enrobant une lambda dont l'opérateur () est static (un truc récent)

Andreas Fertig aborde ensuite la SSO. Il a une implémentation simplifiée (une diapo), mais ça explique bien le concept. Il montre quelques implémentations. Celle de Facebook est intéressante dans son calcul de la longueur

Andreas Fertig présente une FixedString<N> qu'il rend constexpr et montre les effets dans godbolt. Wow, bel effet!

Andreas Fertig poursuit avec std::initializer_list, et montre l'avantage d'une constante static dans une fonction récursive.

Klaus Iglberger – The Most Common Misconceptions (2/N)

Note : je connais le contenu de Klaus Iglberger (j'ai été Technical Reviewer sur son plus récent livre) alors je ne prendrai pas des tonnes de notes, mais je recommande son livre chaleureusement. Je suis surtout ici pour son style et son approche pédagogique.

Klaus Iglberger parle d'abord de CRTP, qu'il situe à l'origine dans un texte de 1995 par James O. Coplien (Curiously Recurring Template Pattern : c'est le nom d'origine et il est resté). Dans la classe de base, il utilise un constructeur par défaut privé, un destructeur privé et fait un ami du dérivé injecté, puis l'interface qui passe par le parent appelle, dans des fonctions publiques non-virtuelles, les fonctions équivalentes de l'enfant en appliquant un static_cast sur this.

Klaus Iglberger fait ensuite référence à l'excellente présentation « Deducing this Patterns» de Ben Deane il y a quelques années et montre comment adapter CRTP en ce sens (ça permet de déduire le type des dérivés tu type déduit!)... et dans quels cas ça ne fonctionnera pas (la déduction se fait sur le type statique, pas sur le type dynamique). Klaus Iglberger souligne que le terme CRTP est ambigu : il y en a deux formes, en pratique. Le CRTP pour fins d'interfaces statiques devrait être une « interface statique » car ça introduit une abstraction (pour Klaus Iglberger il s'agit d'un Schéma de conception). Le CRTP pour injection de fonctionnalités devrait être un « Mixin » car ça n'introduit pas d'abstraction (c'est plus un détail d'implémentation).

Klaus Iglberger demande si on peut remplacer CRTP par des concepts. Belles imitations de Darth Vader et d'un canard en caoutchouc au passage! Il montre qu'on peut resserrer cette approche avec une classe étiquette.

Klaus Iglberger passe ensuite aux variant. Il y va à travers le classique exemple des formes à dessiner et une implémentation du schéma de conception Stratégie. Il ajoute une fabrique... Sa présentation est très bien construite, et il est drôle. Son discours, évidemment, est de ne pas s'arrêter à la surface, de ne pas chercher des solutions trop simples sans réfléchir aux enjeux rencontrés. Ça ressemble beaucoup, en fait, à mon discours de lundi sur le fait qu'au lieu de coder sans réfléchir, de créer des problèmes en même temps qu'on les règles, il vaut mieux prendre du recul et préparer un plan de match.

Klaus Iglberger explique qu'injecter des templates pour que le tout compile n'est pas nécessairement une solution. ll trace ensuite un beau parallèle (diapo 124? 125?) entre les forces et les faiblesses respectives de std::variant et des fonctions virtuelles, mais je pense que sa perspective fonctionne mieux avec un seul type qu'avec plusieurs.

Klaus Iglberger affirme que les schémas de conception représentent des structures de dépendances. Pour cette raison, elles ont des particularités et ne sont pas interchangeables. Il recommande de réfléchir à l'architecture d'abord, puis aux détails d'implémentation ensuite.

Q : (j'ai de la difficulté à comprendre, malheureusement)

Klaus Iglberger : faites vos choix parce que c'est utile, pas parce que c'est joli

Q : as-tu essayé tes benchmarks avec plus de types? Y a-t-il une différence de vitesse?

Klaus Iglberger : non, mais ça va dépendre de l'implémentation.

Q : as-tu remarqué, pour les enjeux de vitesse, des différences entre gcc et clang?

Klaus Iglberger : non, mais ce n'était pas mon objectif non plus.

Q : y a-t-il un monde plus vert entre les méthodes virtuelles et std::variant?

Klaus Iglberger : peut-être mais dans le cas du polymorphisme dynamique ça va être douloureux (sur le plan statique on a des options)

Q : à propos de CRTP (je manque la question, mais Klaus Iglberger recommande un strong type et rappelle que CRTP est souvent utilisé pour représenter cette pratique)

Q : si je veux ajouter de nouveaux types (c'est difficile de comprendre la question, mais la personne qui la pose cherche à articuler ses idées)

Nicolai Josuttis – Taming the C++ Filter View

Nicolai Josuttis dit qu'on doit se parler du filter_view. Il y a un message là selon lui : il y a des surprises, des trucs dont il faut discuter, et il faut comprendre pourquoi.

Nicolai Josuttis montre un exemple simple qui affiche des éléments d'un conteneur un par un avec une boucle ranged for. Il parcourt un vecteur puis un set, les deux initialisés avec les mêmes éléments (ça change l'ordre bien sûr). Il fait ensuite des '|' à travers std::views::take() puis std::views::transform() et c'est chouette.

Nicolai Josuttis itère ensuite à travers une map<string,int> avec des noms et des dates de naissance. Il utilise filter | take | keys et tout va bien. Il fait remarquer que auto est merveilleux car les types manipulés deviennent compliqués

Nicolai Josuttis montre qu'on peut modifier une vue avec filet aussi

Nicolai Josuttis rappelle à quel point C++ est efficace pour parcourir une séquence et opérer sur ses éléments. Il distingue comment une boucle fonctionne et comment une vue fonctionne (belle pédagogie!) avec l'évaluation paresseuse. La schématique est bien pensée. C'est un modèle « pull », des valeurs obtenues sur demande

Nicolai Josuttis montre que faire le transform avant le filter donne un effet différent de faire le filter avant le transform alors l'ordre des transformations fait une différence (en plus, il se peut que les transformations soient faites plus souvent si on n'est pas prudents!). Il rappelle que dans certains cas, on passe des itérateurs et dans d'autres, on passe des valeurs.

Nicolai Josuttis aborde l'enjeu de la « performance » de filter. Il rappelle que pour nos conteneurs :

• L'initialisation par défaut ne coûte pas cher
• begin(), end(), size(), empty() ne coûtent pas cher (à part forward_list qui n'a pas de size())
• operator[] n'est offert que s'il ne coûte pas cher

Nicolai Josuttis explique ensuite le coût de begin() sur un views::filter, et montre que ça peut être un algorithme O(n). Ça peut surprendre mais c'est la seule approche qui soit raisonnable. Pour la même raison, end() et empty() sont O(n) (empty() regarde si begin()==end()); size() et operator[] sont O(n) aussi. Sur des conteneurs, on désactive les opérations trop coûteuses, alors on fait de même avec views::filter ce qui signifie qu'un filter ne supporte pas le Random Access.

Nicolai Josuttis parle des conséquences sur le code générique. On encourage par exemple l'appel de empty() pour tester si un conteneur est vide (size() peut être pire encore). Appeler répétitivement end() sur un view peut coûter cher maintenant alors mieux vaut en faire une copie. On peut vouloir optimiser en appelant empty() avant de commencer à itérer pour accélérer le tout, mais ça appelle begin() sous la couverture... alors on appelle begin() deux fois

Nicolai Josuttis dit que ce qui rend nerveux est les itérations de type « reverse » : rend() va appeler begin() de multiples fois, et on peut avoir un algorithme O(n^2) si on n'est pas prudents. Utiliser un views::filter est par contre très rapide en comparaison avec du code manuel, car elle Cache begin (drop_while et split font de même; drop et reverse le font parfois). Bien entendu, si on modifie le conteneur sous-jacent, l'itérateur en Cache peut être invalidé; pour cette raison, on Cache les positions, pas les itérateurs

Nicolai Josuttis appelle à la prudence, cependant : begin() est coûteux au premier appel seulement, et il en va de même pour end(). Pour les views, begin() et end() ont une complexité O(1) amortie... mais seulement si on les appelle plusieurs fois!

Nicolai Josuttis poursuit avec les conséquences d'une itération qui réalise des lectures. En particulier, passer de manière const auto& un v | views::filter(...) ne compile pas, mais faire le travail sans passer par un paramètre const auto& fonctionne (p.ex. : utiliser auto&& ou faire le code sans appeler de fonction). L'enjeu est que les vues peuvent faire du Caching et ne peuvent donc pas être const. Il préfère le terme Universal Reference (pas moi!). Il faut donc changer certaines de nos pratiques de code générique... ce qui introduit des dangers! Il montre un exemple naïf mais légal en apparence qui utilise du multithreading et provoque une Data Race par des lectures concurrentes (à cause du Caching). Les views ne sont pas nécessairement thread safe. Il montre qu'on peut jouer un tour au système et appeler (void)vw.empty() avant d'itérer, pour forcer le Caching avant d'itérer (ça fait disparaître la Data Race), mais bon...

Nicolai Josuttis propose d'autres avenues, moins malpropres : appeler un std::ranges::subrange() au point d'appel, ou encore passer la vue par valeur (on peut passer un std::ranges::view auto par exemple)

Nicolai Josuttis poursuit avec les conséquences pour les écritures, les opérations qui mutent les éléments. Il montre que le Caching peut jouer des tours (il itère sur des pairs, mais ajoute un, ce qui brise le Caching). C'est techniquement du comportement indéfini (on a brisé le prédicat : on a le droite de modifier les valeurs d'une vue, mais seulement si les valeur modifiées respectent toujours le prédicat)

Nicolai Josuttis me cite bel et bien avec des monstres (une boucle pour ressuciter les monstres morts à travers un filtre est du comportement indéfini)

Nicolai Josuttis donne quelques exemples :

• Itérer une seule fois (créer le pipeline, l'utiliser, le jeter) fonctionne... mais pourquoi cacher begin()? Pour reverse...
• Passer une vue en paramètre à une fonction est délicat, mais on peut passer à la fonction ce qu'on veut appliquer et construire le pipeline à l'interne... Mettons (on peut avoir du comportement indéfini ici aussi)
• Les comportements obtenus sont parfois différents en fonction du conteneur sous-jaçant
• Le simple fait d'imprimer une vue existante provoque du Caching de begin() et peut influencer la suite des événements

Nicolai Josuttis demande si on peut « dé-Cacher »les valeurs en Cache... On peut copier la vue, et ça va peut-être fonctionner. Peut-être...

Nicolai Josuttis résume le propos. Je pense qu'il n'est pas content du design 🙂 Ses recommandations sont (a) de placer les filtres tôt dans un pipeline, (b) les appliquer ad hoc, (c) éviter de modifier les éléments par un filtre (ou du moins, si vous le faites, ne brisez pas le prédicat), (d) ne pas modifier les ranges sous-jacents après application d'un filtre, (e) n'utilisez pas des filtres dans du code concurrent...

Nicolai Josuttis aborde les enjeux de design qui lui semblent problématiques (ça impacte l'idée-même de const). Il y en a quelques-uns selon lui, en partie à cause du Caching de begin() qui n'est pas transparent

Q : recommandes-tu d'utiliser filter dans les circonstances?

Nicolai Josuttis : j'enseigne beaucoup C++20. Une option est de ne pas utiliser les views du tout... Um drop_view a des enjeux aussi. C'est un outil un peu périlleux pour les débutants. Je préférerais qu'on corrige les bogues

Q : peut-on invalider les itérateurs?

Nicolai Josuttis : les itérateurs ne savent pas sur quoi ils itèrent

Q : belle présentation. Je pense qu'on peut corriger certains de ces irritants, et qu'on devrait le faire

Nicolai Josuttis : j'ai une proposition nommée « Healing the Filter View » en ce moment (on parle de rendre le Caching explicite)

Q : est-ce qu'on est pris avec ça pour toujours?

Nicolai Josuttis : on brise du code parfois (ça compile, mais ça se comporte différemment). On ne fait pas exprès, mais ça arrive. Chaque nouveau mot-clé brise quelque chose, si on y pense... On l'a fait pour les Range-Based for loops récemment

Q : tu as mentionné que ne faire qu'une passe et modifier les éléments de manière à ne pas respecter le prédicat de filtrage est du comportement indéfini mais fonctionne... Pourrait-on préciser ce qui est indéfini pour clarifier que cela est correct?

Nicolai Josuttis : c'est une option, mais il y a d'autres problèmes

Q : on connaît le problème dans SG9. On a quelques nouveautés pour SG26 qui règlent ces problèmes

Committee Fireside Chat

Les participant(e)s de ce soir sont Herb Sutter, Andrei Alexandrescu, Daisy Hollman, Dietmar Kühl, Gabriel Dos Reis, Khalil Estell, Lisa Lippincott, Michael Wong et Timur Doumler. C'est Herb Sutter qui anime, et il débute par un « tour de table » en demandant aux gens présents ce qui les intéresse le plus dans le futur de C++ (on parle de contrats, réflexivité, std::execution, la sécurité et le Machine Learning)

Guy Davidson : pourquoi est-ce si long avant d'avoir les contrats?

Lisa Lippincott : ma présentation de jeudi porte précisément sur cela

Michael Wong : on a remarqué que les gros « features » prennent parfois des années à déboucher. On aimerait trouver un moyen d'améliorer cette situation. Le pire, je pense, est Networking

Daisy Hollman : la réflexivité a été vraiment longue à... incuber, mais on a tellement d'implémentations à harmoniser. C'est tout un défi

Timur Doumler : les raisons pour les contrats et la réflexivité sont différentes. On a sondé la communauté pour les cas d'utilisation des contrats... On en a trouvé plus de 150 distincts. Faut prioriser

Andrei Alexandrescu relate que les exemples de réflexivité tiers ne sont pas excitants et se limitent souvent à du logging et à la conversion d'enum en string

Daisy Hollman : la réflexivité est parfois ardue, par exemple sur les noms de paramètres

Q : il est parfois sage de prendre son temps. En tant qu'usagers, on manque de temps pour les absorber (Herb Sutter demande à la foule qui trouve que C++ bouge trop lentement, puis qui trouve qu'on bouge trop vite : c'est à peu près moitié-moitié)

Michael Wong : ça dépend des domaines. Par exemple, les gens du monde des systèmes embarqués sont toujours deux générations derrière car ils doivent valider les binaires...

Gabriel Dos Reis : pourquoi pense-t-on qu'on doit livrer des « features » chaque trois ans? (il prêche pour les changements de type « avènement de la STL », et rappelle ce qui a mené à constexpr, en partie parce qu'il était tanné de voir des macros)

Lisa Lippincott : si on ne les livre pas, ils s'empilent et accumulent la poussière (Dietmar Kühl va dans le même sens; Herb Sutter pense que ça donne confiance à la communauté, car on livre à temps)

Andrei Alexandrescu rappelle que les années « hivernales » de C++ étaient de 2004 à 2010, la période entre les standards

Lisa Lippincott : la standardisation n'est pas un enjeu de programmation. C'est l'édition d'un énorme document et l'acte de convaincre des gens que les changements qu'on veut lui apporter sont avantageux, de bâtir une forme de consensus, de chercher à accroître la clarté d'un texte

Michael Wong parle du processus qui mène une proposition de l'inspiration au comité, jusqu'à une éventuelle adoption. C'est long, mais c'est rigoureux

Q : à propos du Borrow Checker de Sean Baxter et d'autres propositions pour rendre C++ Memory-Safe...?

Gabriel Dos Reis : j'ai lu la proposition. On fait évoluer le langage, et pour cela on accepte ce qui existe et on essaie de le faire progresser, sans briser tout ce qui existe. Les travaux de Sean Baxter sont intéressants et prouvent qu'il est possible d'implémenter ces idées de Rust dans C++, mais je ne suis pas convaincu (je peux le devenir). C++ a eu du succès, pas parce qu'il est parfait ou 100% correct dans tous les cas, mais bien parce qu'il permet de solutionner une vaste gamme de problèmes. J'ai travaillé sur plusieurs aspects de la sécurité dans le langage au fil des ans

Herb Sutter dit que la question a été posée hier alors qu'il va passer à une autre question

Q : on a beaucoup parlé de Memory Safety et de Type Safety, mais pas beaucoup de Functional Safety. Dans mon domaine, l'aérospatiale, nous sommes préoccupés par la « magie » injectée dans les binaires. Réfléchit-on à ces questions?

Lisa Lippincott : mon souper ce soir a été en grande partie consommé par une discussion à ce sujet entre Timur Doumler et moi-même. On ne veut pas cacher de trucs, mais on ne veut pas compliquer votre vie non plus...

Michael Wong dit avoir examiné ce vaste sujet, dans le contexte de systèmes critiques. La Functional Safety est une obligation légale, mais n'est pas indépendante des autres aspects de la sécurité. La sécurité est une question de couches, de strates; c'est quand le tout est intégré qu'on parle de système Functional-Safe

Gabriel Dos Reis : si on demande aux gens de tout écrire, ils risquent d'en oublier...

(je dois quitter, même s'il reste une demi heure, car je lutte contre le sommeil et je n'ai pas encore soupé)

Andreas Weis – Deciphering Coroutines - Recap and Prerequisites

Je ne suis pas parvenu à arriver à temps, zut!

Dmitry Prokoptsev – Coroutines and Structured Concurrency in Practice

Note : je suis arrivé avec une quinzaine de minutes de retard alors je suis un peu hors-contexte. Ça semble pas mal de ce que je peux voir, mais c'est une impression (je ne sais même pas où Dmitry Prokoptsev en est rendu car il n'y a pas de numéros sur des diapos – une très mauvaise idée)

Dmitry Prokoptsev présente des exemples de code un peu suspects, mais ce qu'il met de l'avant est l'enjeu de la gestion de la durée de vie des objets dans un contexte de concurrence structurée (std::execute, coroutines) alors il essaie de passer un message (il demande des destructeurs asynchrones... Bon). J'aime bien son résumé des fonctions clés d'une coroutine (c'est un truc qui sera utile; je vais essayer de regarder le reste de la présentation que elle sera en ligne)

Dmitry Prokoptsev parle d'annulation et insiste sur le fait que if(cancelled) return; ici et là n'est pas raisonnable. Il faut que ce soit rapide, ne repose pas sur une levée d'exception, et asynchrone. Il y a des opérations qui ne peuvent tout simplement pas être annulées de manière synchrone (il donne une courte liste, par exemple un processus qui fait des entrées / sorties). Il donne les grandes lignes d'une procédure d'annulation quu lui semble raisonnable, et explique pouquoi il faut un peu de collaboration de la part du awaitable

Dmitry Prokoptsev décrit plusieurs avantages de son approche : il parle d'une réduction de la taille du code, mais c'est pas clair s'il parle de code source ou des binaires, et d'une simplification du flot d'exécution, de même qu'une mécanique uniforme d'annulation. github.com/hudson-trading/corral

Une question est posée à propos des annulations asynchrones, mais j'ai trop manqué de la présentation pour suivre le discours de manière pertinente

Amanda Rousseau – Embracing an Adversarial Mindset for C++ Security

Amanda Rousseau est ici pour nous parler de sécurité. Elle se présente de manière schématique; elle fait de la recherche en sécurité pour Microsoft après avoir travaillé chez Meta. Elle est @malwareunicorn sur Twitter. Elle dit passer 75% de son temps à regarder du code, le reste à écrire des harnais de tests, écrire des outils, etc.

Amanda Rousseau parle du Adverserial Mindset, un truc qu'on n'enseigne pas selon elle. L'idée est de penser comme un adversaire. Elle présente l'idée de vouloir une tasse de café gratuite, et donne plusieurs manières d'y arriver, du mode « peu d'effort » au mode « beaucoup d'effort ». Ensuite, elle présente une application qui lit un fichier, le sérialise, le passe à un service d'OCR et transmet le texte résultant, puis elle montre des vecteurs d'attaque à chacune des étapes (il y en a beaucoup)

Amanda Rousseau poursuite avec le Adverserial Motivation, donnant quatre grandes catégories (catégorisées par effort). Elle parle de Privilege Escalation (medium effort), Lateral Movement (medium-high effort), Remote Execution (high effort) et Denial of Service (low effort) et de ce qui tombe dans chacune

Amanda Rousseau explique les modes et les tendances, avec la perspective de Microsoft. Elle aborde les facteurs qui influencent ces tendances. Des trucs comme l'infonuagique et le travail à distance font partie du discours mais il y en a beaucoup, par exemple l'évolution des lois et des réglements, la vie privée, etc. Elle parle des Bug Bounty Programs (chez Microsoft, le plus payant est à 250K USD dans le cas d'une capacité d'exécution à distance)

Amanda Rousseau dit que le problème numéro un demeure les enjeux de Memory Safety, mais il y en a 6-7 autres dans son palmares. Elle décrit des trucs amusants comme le Heap Grooming par exemple que je ne connaissais pas. L'exécution de code à distance est difficile mais payante (je manque quelques exemples dû la préparation de la rencontre de SG14). Elle parle du Nokoyama Ransomware qui se cachait dans une exception (CVE-2023-28252 si j'ai bien vu) et qui passe par un fichier .blf (Base Log Format). Elle explique cette attaque en détail, c'est intéressant et on en vient à prendre le contrôle du noyau du système d'exploitation. Elle dit que ce genre de truc se répand parfois dans la nature et ça peut déraper

Amanda Rousseau présente le BITTER APT group, avec CVE-2021-28310 et CVE-2021-1732 qui sont tous les deux des attaques pour obtenir une escalation de privilège en modifiant les membres d'un struct passé lors d'un Callback

Amanda Rousseau présente PrintNighmare & Russia State-Sponsored Threat Actor qui est CVE-2021-1675 et CVE-2021-34527 et exécute du code à distamce à travers le Spooler de Windows. Ils utilisent une DLL malicieuse pour fins d'escalation de privilège en utilisant un service d'installation de pilote à distance

Amanda Rousseau présente Raspberry Robin Malware and Ransomware (CVE-2020-1054 et CVE-2021-1732), qui utilise un bitmap mal foutu pour causer des dégats (quatre lignes de code suffisent)

Amanda Rousseau demande quelle est notre surface d'attaque. Il faut commencer par définir les frontières de notre confiance (Trust Boundaries), soit le point où on passe d'une zone où il y a un composant envers lequel on n'a pas de confiance vers une zone de confiance. Par exemple : désérialiser des données, télécharger un truc d'Internet, passer par de la mémoire partagée, des fichiers de configuration, des logs, des pilotes, des ports partagés avec un Sandbox, etc. Microsoft a un outil nommé le AttackSurfaceAnalyzer offert sur github. Elle recommande de connaître notre surface d'attaque et d'isoler les zones à risque

Amanda Rousseau revient sur son application d'OCR initiale pour décrire les techniques de modélisation des menaces. Elle trace les frontières de confiance dans son schéma. Elle recommande de réduire les entrées faites par un usager, le recours au code concurrent (trop de gens ne savent pas comment faire), activer les options de sécurité du compilateur, etc.

Amanda Rousseau aborde ensuite les stratégies de développement sécuritaire en C++.  Elle trace d'abord la ligne du temps des principales approches pour mitiguer les tentatives d'exploitation au cours des vingt dernières années. Les principales stratégies de défense sont la protection du flot de contrôl et ce qu'elle appelle du Shadow Stack (technologie récente). Elle parle de la règle de deux : on a Processing Untrustworthy Input, Using Unsafe Language, et High Privilege or No Sandbox, et dit qu'on ne peut pas en avoir plus de deux. Par exemple, si on consomme du JSON qui vient d'Internet, faut rouler le code dans un processus ayant peu de privilèges. Elle revisite son application pour tenir compte de ces recommandations

Amanda Rousseau : les principes de base de la programmation sécuritaire sont Trust no-one, Don't assume anything and question anything, Beware of weak contracts, et (il m'en manque un). Elle donne quelques exemples avec des indices, des casts, l'identité du processus appelant, les enum, le recours aux pointeurs... Elle recommande des span (ceux de la GSL), l'initialisation sécurisée de la mémoire, les assertions et les blocs try-catch peuvent masquer des bogues, il faut faire attention et bien délimiter la profondeur maximale d'appels récursifs.

Amanda Rousseau réfère à la GSL et aux Core Guidelines. Elle liste aussi des options de résilience et de sécurité de MSVC. Elle liste ensuite les fonctions « bannies » (elle bannit malloc() et memcpy(), mais dans mon domaine c'est hors de question; les autres, je suis à l'aise... Mais si on ne les bannit pas, il faut examiner leur utilisation de près!)

Amanda Rousseau aborde la question sensible du code ouvert. Elle recommande la présence de Fuzz Testing si on inclut de telles bibliothèques (c'est un signe que la sécurité a été une préoccupation dans la mise en place du système), et elle recommande d'étudier les pratiques de réparation de bogues avant d'adopter quoi que ce soit

Amanda Rousseau discute d'isolation, par exemple de faire le traitement de l'entrée des données hors du processus. Elle recommande des Sandboxes, des AppContainers. Elle parle beaucoup de Fuzzing, incluant Fuzzing as a Service. Elle recommande de combiner LibFuzzer et Address Sanitizer ensemble (elle explique comment le configurer; ça tient sur une seule diapo)

Amanda Rousseau revient sur l'importance d'avoir la sécurité en tant qu'état d'esprit. Elle récupère les divers points de sa présentation et les remet en contexte (bien fait!). Essayez de penser comment attaquer votre propre programme... Elle fait un parallèle avec le Supply Chain Attack terrible qui a décimé des agents du Hamas cette semaine (les « pagers »explosifs... Brrrr...)

Andreas Weis : cette conférence porte sur un langage de programmation, et nous recevons beaucoup de critiques. Tu nous a montré plusieurs tactiques de mitigation. Y a-t-il de l'espoir?

Amanda Rousseau je ne vois pas C++ disparaître, surtout pas rapidement, mais il faut prendre action

Q : tu as dit que try-catch est problèmatique à quelques reprises. Quelles sont les alternatives?

Amanda Rousseau : quitter tôt plutôt que d'essayer de tout régler

Andreas Weis : et tu nous recommandes d'éviter les assert(). Des détails?

Amanda Rousseau : les assertions sont pour planter rapidement, pas pour valider

Q : on est préoccupé dans mon domaine (le jeu) par les usagers qui essaient de prendre le contrôle de nos programmes. Que peut-on faire?

Amanda Rousseau : on peut écrire un Cheat Engine (j'ai manqué les détails), La simple action de charger un fichier sans vérifier son intégrité est un problème, et ça n'a pas à être un problème de C++

Q : quand on n'a pas de système d'exploitation, à quoi doit-on faire attention?

Amanda Rousseau : je ferais attention aux Side-Channel Attacks

Q : on utilise beaucoup memcpy(). Comment intégrer ça à une approche par Fuzzing?

Amanda Rousseau : il y a une version sécurisée de memcpy(), sinon on peut faire s'exécuter l'appel dans un autre processus

Q : quelle est ta vision du Rule of Two si C++ devient plus Memory-Safe?

Amanda Rousseau dit que c'est d'abord un enjeu d'adoption

(on parle un peu du système Anti-Cheat de Microsoft; elle rappelle que les antiviraux sont essentiellement la même chose que du Malware)

Erez Strauss – xstd::any - A New Container for Any Type with Extra Features and Small Object Optimization

Erez Strauss propose une variante de std::any qui serait enrichie sémantiquement. J'ai regardé le début de son exposé; c'est bien mais il y a quelques raffinements qu'on pourrait y apporter pour le rendre encore meilleur. Je n'ai toutefois pu voir que les 20 premières minutes environ...

Official ISO C++ WG21 SG meeting of low latency/embedded/games/finance and Machine Learning

Vous ne verrez pas de notes ici parce que ces rencontres ne sont pas publiques, mais les grandes lignes sont :

• Nous avons tenu une rencontre conjointe SG14 (systèmes à basse latence) et SG19 (Machine Learning)
• Les propositions pour SG19 portaient sur std::graph, sur les algorithmes qui l'accompagnent, et sur std::statistics
• Les propositions pour SG14 portaient sur des nombres à virgule flottante aux résultats reproductibles, pleinement conformes à ISO IEC 60559 (donc à IEEE 754), une proposition portée par Guy Davidson; sur [[invalidate_dereferencing]], idée portée par votre humble serviteur, de même que sur les travaux de Khalil Estell sur les exceptions et leurs coûts (une étude en profondeur dont il a fait état des résultats lors du Keynote d'hier)
• Il y avait beaucoup de gens au début (un classique), et la salle s'est vidée de moitié quand les autres conférences ont recommencé (ces rencontres, c'est pas la tasse de thé de tout le monde). On avait une dizaine de participant(e)s en ligne car la rencontre était hybride
• Ce fut intéressant, fécond, et ça a duré près de quatre heures

Andrei Alexandrescu – Reflection is Not Contemplation

Il est important que je vous dise d'office que je n'ai pas pris de notes. J'en avais beaucoup pris toute la journée et j'étais un peu fatigué alors je me suis pris un verre d'eau, je me suis installé au fond de la salle et j'ai simplement profité de la présentation.

Andrei Alexandrescu explique sa vision de la réflexivité

Phil Nash – Lightning Talks

Phil Nash est seul aujourd'hui mais Michael Caisse sera à l'animation demain soir. On y va.

Miodrag Misha Djukic - « The Main Points of C++ » parle... de points, comme dans 4.2, et du rôle du '.' dans le langage. Il en rapporte 3 ou 4 : le '.' dans les littéraux flottants, le '.' dans l'accès aux membres ('.' et ".*"), et dans les noms de modules. Pour les ':' il en compte 10 ou 12. Pour les "..." il en rapporte 6. Enfin, il rapporte 3 ou 4 cas de "::" (il ajoute [:e:] en C++26)

Matt Aber - « The Present and Future of Cross-Platform GUI in C++ » parle de trucs comme Qt, puis de Electron et Chromium pour le Web (mais ces trucs coûtent cher en ressources), puis de compiler en C++ natif et de compiler pour WebAssembly (malgré les limites de la plateforme). Il parle de Wasmer et de WasmEdgeRuntime pour tu WASM hors du fureteur, puis de WASI (WebAssembly System Interface) qui est plus complet et qu'il nous vante. Il rapporte que l'écosystème de WASI semble favoriser Rust ces temps-ci, par contre, et dit qu'il aimerait que ça change pour mieux inclure C++

Patrick Roberts - « Customizing Compilation Error Messages » parle de formatage de chaînes de caractères à la compilation. Il a bâti une bibliothèque de réflexivité à l'aide de C++20 (avec Kris Jusiak). Ses diapos sont difficile à lire du fond de la salle quand elles incluent du code

Jonathan Müller - « Can't we just synthesize std::tuple_element from get? » parle de ses difficultés à poser cette question avec get<I> qui retourne des références et avec lequel il faut se battre pour bien gérer les &, &&, const... et il ne vient à suggérer de ne pas utiliser std::tuple_element tout simplement

Lexington Brill - « Micro-Benchmarking & Murphy's Law » parle de mesurer quelque chose de très bref, de l'ordre de la nanoseconde par exemple. L'acte d'observer impacte le résultat. Il parle des précautions à prendre pour avoir une mesure de qualité (ses suggestions sont parfois suspectes, mais plusieurs sont raisonnables)

Kevin Carpenter - « CppDefCon3 » parle de WARGAMES (un vieux film!) et c'est fort amusant. En plus, sur l'écran de Netflix ou Prime il y a ... un livre de C++ par Bjarne Stroustrup... sorti en 1985... pour un film sorti en 1983!

Andrew Kaster - « Improving an HTML Parser with Pattern Matching » parle... d'un Tokenizer, pas d'un Parser, très bien spécifié avec beaucoup d'états. Il essaie avec Ladybird de respecter les spécifications de manière rigoureuse. Il a fini par l'écrire en Swift pour avoir le Pattern Matching

Helen Altshuler - « Do you Love or Hate your Build System? » parle de son expérience avec un système de Build et de Tests. Le but est de livrer, « to get things done ». Elle sonde la salle pour savoir qui utilise CMake... et qui l'apprécie. Elle fait de même avec Bazel. Puis avec MSBuild. Puis avec des systèmes « maison ». En gros, environ une personne sur deux est heureuse de son système de Build. Elle travaille sur Bazel et nous en parle en plus de détail

Dave Steffen - « The Number Of The Counting » parle de standards de présentation de code, et dit que ceux-ci visent à maximiser la lisibilité. La plus importante décision est... de combien indenter (n'importe quoi...). Il trace une courbe, et le soft spot est... 3, bien entendu (et il le présente visuellement!)

Cassio Neri - « Saturday is coming faster - Part 1 - The magic » parle de deux manières de calculer year_month_day plus rapidement que la technique appliquée dans le standard, et il rapporte des bogues menant à du UB dans certaines implémentations de la bibliothèque standard. Son implémentation utilise un calcul de n%7 qui est très rapide (et très obscur), mais seulement pour environ... les premiers 12 millions de jours de calendrier. Il utilise [[assume()]] pour son optimisation

Andreas Fertig - « The UB Detector: constexpr » parle de... la détection de UB à l'aide de constexpr, mais signale qu'il peut s'en échapper un peu. Il donne quelques exemples, un avec un views::filter (Nicolai Josuttis va être content) et un avec une fonction [[noreturn]] qui retourne quelque chose

Damien Buhl - « Mixology: The Rusty C++ Mule » parle d'intégration de C++ avec Rust. Il vante au passage son produit, tipi.build et fait des jeux de mots

Alon Wolf - « Generative C++ » parle de génération de code, mais ça va très vite (il génère des Shaders)

Luis Caro Campos - « DevSecOps for C++? Keep Calm and Use Conan » parle de réaction face à une crise de dépendances et vante Conan qui peut retomber sur ses pattes même lors d'un bris de connectivité avec Internet (c'est la guerre des systèmes de Build, ma foi!)

Phil Nash - « The Current State of AI » parle... de la séie Terminator: The Sarah Connor Chronicles, et d'une citation laissant entendre qu'une IA ne peut pas générer d'Art. Il a soumis une demande de photo à ChatGPT et c'est impressionant

Andreas Weis – Deciphering C++ Coroutines - Mastering Asynchronous Control Flow

Andreas Weis débute en expliquant que cette présentation est la deuxième d'une série. Il commence par examiner la question du type de retour d'une coroutine. En C++ contrairement à plusieurs autre langages, nous n'avons pas besoin de types de retour spéciaux (même si nous pouvons en écrire, évidemment). Il parle de cet aspect comme un user-facing interface

Andreas Weis parle ensuite du promise_type, partie du compiler-facing interface. Il en va de même pour le awaitable qui explique ce qui se passe lors d'une suspension ou d'une résomption. Il a un joli schéma nommé Map of the coroutine land (il y a une URL que je mettrai ici bientôt). Il recommande une présentation de 40 minutes par Andrzej Krzemieński à Code::Dive 2023

Andreas Weis explique pourquoi passer par std::async() et des futures est une solution qui fonctionne, mais qui est dispendieuse et requiert de la synchronisation pour les données partagées. Il y va ensuite pour une approche par « green threads » ce qui mène à une forme de multiprogrammation collaborative. C'est plus léger, ça ne demande pas de synchronisation, mais c'est pas préemptif alors ça comporte d'autres enjeux bien entendu.

Andreas Weis aborde la question des coroutines de C++20 qui sont Stackless et ne permettent que de suspendre une fonction à la fois (si on veut en suspendre plusieurs, faut le faire une à la fois). Il réalise une lecture bloquante sur un réseau; l'introduction de co_await et (surtout) co_return impose de retourner quelque chose qui soit awaitable. Ses objets de type Async<T> ont un double rôle de coroutine et de awaitable

Andreas Weis : you cannot resume coroutines from the outside in. Une coroutine résumée ne sera suspendue à nouveau que si on la co_await. Il présente ensuite la pile d'exécution comme une liste chaînée, puis il construit son Async<T> étape par étape. Le await_suspend() reçout un std::coroutine_handle<> modélisant l'appelant de la fonction, ce qui permet de reproduire la pile des appels (exprimée sous forme de liste chaînée). Belle pédagogie! Il réalise ce qu'il décrit comme un symmetric transfer (on change l'appelant sur la pile des appels). Sur le plan pédagogique, il a besoin de fonctions inner(), middle() et outer() (je pourrais construire un exemple s'en inspirant; si je procède, je vais le citer). Il retourne ResumeCaller de final_suspend() pour réaliser le transfert de contrôle entre appelé et appelant

Andreas Weis montre le rôle d'un ordonnanceur dans la mécanique, mais estime irritant qu'on ajoute ce paramètre alors il le loge plutôt dans son Async<T>::promise_type, avec son std::coroutine_handle<>. Le T dans Async<T> est le type de retour, alors await_suspend(std::coroutine_handle<T>) doit être un template. Il faut que les promesses aient une forme d'uniformité (un MyPromiseConcept par exemple)

Andreas Weis en vient à représenter le lien appelant / appelé par une liste doublement chaînée (Mark Hoemmen me fait remarquer que c'est pas mal la même idée que les environnements avec les senders / receivers). Pour visualiser ce qui se passe (pédagogie) il utilise un débogueur avec un NatVis fait sur mesure. Il montre comment transformer un coroutine_handle en arbre (plusieurs « enfants ») puis en graphe (plusieurs enfants et plusieur parents)

Andreas Weis met de l'avant qu'avec toute cette flexibilité, les « meilleures pratiques » demeurent à définir. Le bon côté est que, au fond, c'est une opportunité!

Erez Strauss : peut-on capturer une lambda dans le type de retour?

Andreas Weis : bien sûr!

Fedor Pikus : peux-tu clarifier la relation entre appelant et appelé et le passage de l'information quant à l'ordonnanceur?

Andreas Weis : un exemple concret serait le IO Context de Boost::ASIO (il entre dans le détail, mais l'idée est qu'on y retrouve l'information requise pour l'appelant et l'appelé, donc qui n'est pas locale à l'un ou à l'autre)

Q : les coroutines sont standardisées depuis quelques années, mais les utiliser semble être un domaine de recherche. A-t-on standardisé trop tôt?

Andreas Weis : on n'a standardisé que le minimum nécessaire, il faut encore construire autour...

Q : les coroutines sont présentées comme plus flexibles que des « green threads ». Sont-elles meilleures pour des entrées / sorties?

Andreas Weis : il y a des avantages aux « green threads ». Si on utilise des coroutines, il faut que toutes les fonctions dans la chaîne d'appels soient des Async<T> donc des coroutines. C'est viral!

David Gross – When Nanoseconds Matter: Ultrafast Trading Systems in C++

David Gross se présente, puis situe sa présentation dans un contexte historique (il remonte à l'antiquité romaine). Il parle des pratiques contractuelles de l'époque, qui visaient à réduire l'incertitude envers les événements du futur, en particulier les turbulences économiques

David Gross annonce sans surprises qu'il va parler de basse latence. Il présente le Market Making comme un Losers' Game : on fait de petits profits, on essaie d'éviter les grosses pertes. Il dit qu'on a besoin d'une combinaison entre « être rapides » (réagir rapidement aux événements du marché) et « être astucieux ». Il présente un schéma où on voit ce qui est du registre de la microseconde et ce qui est du domaine de la nanoseconde, tout en insistant sur le fait qu'il faut être rapide, mais aussi précis (accurate). En fait, faut être précis rapidement

David Gross dit que le logiciel qui alimente les FPGA et détermine les stratégies opère habituellement dans les microsecondes. Il explique ensuite ce qu'est un Order Book, entité au centre d'un système transactionnel : on voit les offres d'achat et les offres de vente, et on choisit ce qui maximise notre profit. Ça implique lire des paquets dans des tampons sans en perdre. On a besoin d'un hash_map pour ce genre de travail, mais il utilise std::map dans la présentation pour simplifier le propos et rappelle que les itérateurs sur ce type sont stables face aux insertions et aux suppressions. Évidemment, la plupart du temps, on ne veut pas de conteneurs à base de noeuds, alors il montre comment faire un travail analogue avec des std::vector. La complexité est moins bonne, les itérateurs sont moins stables, mais bon... :)

David Gross présente une distribution comparative des latences dans les deux cas (map et vector) et dit qu'elles sont... Ok, sans plus. Il améliore la situation en réduisant un peu les copies, et recommande d'examiner les données pour mieux comprendre les problèmes

David Gross ajoute que les algorithmes spécialisés sont la clé pour tirer plus de performance d'un logiciel. Il utilise perf pour ses tests, et l'applique sur ses benchmarks, en particulier perf record -g -p <pid> pour conserver des traces. Il écrit un branchless binary search et obtient des gains. Ensuite, il examine les opérations de la recherche dichotomique qui, initialement, ne sonnt pas cache-friendly... Il fait des tests et une recherche linéaire est plus rapide, ce qui lui fait dire « simplicity is the ultimate sophistication »

David Gross enchaîne avec la Mechanical Sympathy. Il tire profit de [[likely]] (c'est le genre de truc qui aide quand nos données ont une forme particulière), puis example l'impact des IIFE. Il compare ensuite les lambdas, les foncteurs et std::function pour constater les conséquences

David Gross : l'étape suivante est le transport à basse latence, et la réseautique (qui réside en User Space selon lui). Il mentionne OpenLoad et TPCDirect à titre d'outils (TCPDirect est radivalement plus rapide)

David Gross ajouter un prinmcipe : l'efficacité réelle vient des couches superflues qu'on enlève pas de celles qu'un ajoute. Il utilise de la mémoire partagée (pourquoi ajouter des sockets si nos processus partagent un même serveur? Ça permet aussi d'escamoter la médiation do noyau. Ça demande d'utiliser des tablaux bruts, et idéalement un producteur et un consommateur

David Gross aborde une file concurrente (c'est Erez Strauss qui va être content!) de capacité fixe, non bloquante. Il insiste sur l'importance de choisir le bon outil pour chaque tâche, puis décrit sa file (c'est essentiellement ce que je fais au DDJV l'hiver, mais avec des atomiques dont les compteurs font des opérations store_release en écriture et des load_acquire en lecture). Après benchmarks il pense pouvoir faire mieux; ses optimisations incluent mettre en Cache le write counter (pour réduire la contentoin), jouer sur l'alignement en mémoire et mettre en Cache le read counter

David Gross dit que l'étape suivante est l'approche Zero Copy. Réduire les copies peut sauver beaucoup de temps

David Gross passe au point de mesurer la vitesse d'exécution dans un système à basse latence. Il rappelle que perf record fait de l'échantillonnage, ce qui impacte les métriques. Dans son code, il préfère lire les rdtsc.

David Gross aborde la question de chercher les goulots d'étranglement. C'est un peu comme fouiller dans le noir... à moins d'avoir des outils, un plan. Il utilise Xray de Clang, et montre comment réduire l'overhead des mesures à l'aide de cet outil. Il discute ensuite des tendances et des audits (ces derniers sont nécessaire). Principe : c'est bien d'être rapide, c'est mieux de le demeurer

David Gross termine en rappelant aux gens assemblés qu'elles ou ils ne sont pas seul(e)s. Il montre du code de benchmark qui ressemble beaucoup à ce que je fais en classe, mais mesure avec Google Benchmark. Il recommande de ne pas oublier de réfléchir au système dans son ensemble, de manière holiste, pas seulement par morceaux. Et son dernier principe est que la « performance » du système dépend autant du code des collègues que du nôtre

David Gross : comme le marché, la basse latence est aussi un Losers' Game. Faut être discipliné(e), faut éviter de donner dans le « over engineering »... et ne pas oublier cet enjeu de latence qu'est le « time to market » : faut livrer!

Q : as-tu essayé un hybride entre recherche linéaire et recherche dichotomique?

David Gross : oui, effectivement, je l'ai essayé. Les collections n'étaient pas assez grandes pour que la recherche dichotomique batte la recherche linéaire

(quelques questions sont difficiles à déchiffrer, malheureusement)

Q : tu as mentionné le recours à de la mémoire partagée et à du zéro copie, mais dans le Keynote d'hier on nous a présenté cela comme un vecteur d'attaque...

David Gross : c'est un domaine différent. Je dois être rapide, faut sécuriser les frontières...

(je manque quelques questions parce que je parle avec Chris Ryan et Andre Kostur)

Lisa Lippincott – Perspectives on Contracts

Lisa Lippincott me disait cette semaine que cette présentation était en fait quelque chose qu'elle a présenté au comité de standardisation lors de la rencontre de St-Louis cet été, mais je n'en ai pas profité parce que j'étais à distance pour cette rencontre.

Lisa Lippincott explique que son sujet de prédilection, Program Correctness, n'est pas tout à fait ce qu'on a au menu aujourd'hui.

Lisa Lippincott rappelle un algoritme qu'on lui a enseigné sur la soustraction des entiers. On lui avait recommandé d'additionner deux valeurs pour retrouver la troisième dans l'optique de valider le travail. Ça lui semblait redondant; aujourd'hui, ce serait une assertion. Elle rappelle qu'on a un désaccord sur les assertions quand on a des points de vue différents. Elle parle de l'efficacité qui peut aller à l'encontre de la redondance, cette dernière servant surtout à la détection des erreurs. Elle rappelle que assert() est une macro, ce qui permet (sur la base de NDEBUG) de décider si un binaire visera l'efficacité ou la détection des erreurs.

Lisa Lippincott indique qu'en C++, on a NDEBUG ou pas non pas par unité de traduction mais bien par programme. Quand deux programmes compilés différemment se parlent, ça peut très mal se passer. C'est la faute de... vous, les programmeuses et les programmeurs, mais bon, on ne vous la rend pas facile

Lisa Lippincott donne une vision des mots choisis pour réconcilier tout ça : une expression sera évaluée n fois, et n peut être zéro. C'est ce qu'on a avec les contrats et contact_assert(). C'est ... vague

Lisa Lippincott dit que c'est la racine du problème : on offre quelque chose de grand, d'inclusif, mais les programmeuses et les programmeurs ont des besoins spécifiques, et n'apprécient pas vraiment que les besoins des autres peuvent être différents. C'est un cas où l'inclusivité semble encore plus vaste... parce que ça vous touche, parce que c'est important pour vous. D'un point de vue, la présence ou l'absence de contrats ne change pas le programme, mais d'un autre point de vue ça fait une grosse différence

Lisa Lippincott dit qu'on a besoin d'une manière pour naviguer à travers ces deux points de vue. Le truc : une assertion ne devrait pas faire quelque chose de signifiant, mais devrait dire quelque chose de signifiant. Il peut y avoir des effets (p.ex. : amener une valeur en Cache), mais pas d'effets signifiants. Si on ne parlait que de contract_assert(), ce serait la fin de l'histoire

Lisa Lippincott passe ensuite aux préconditions et aux postconditions. Ces deux étapes forment... un contrat entre l'appelant et l'appelé. Ça permet de savoir de quel côté de la clôture un bogue se trouve, le cas échéant. Il se trouve qu'en C++, nous sommes aussi préoccupés par les unités de traduction, et que les bogues tombent parfois dans les fossés entre ces unités de traduction (elle élabore un schéma plus complexe qui exprime cette idée). Elle apporte un autre point de vue sur les préconditions (forward-facing pour l'appelant, backward-facing pour l'appelé) et les postconditions (l'inverse). Comme elle le fait souvent, elle parle de l'entité qui cherche à trouver la source d'un bogue et de celle susceptible de causer le bogue. Pour les préconditions, on tend à se protéger en laboratoire devant du code nouveau ou fragile. À l'interne, on veut se protéger de situations qui pourraient causer des dégâts (ça joue sur la validation caller-checked – nouveau code – et callee-checked – ça va briser quelque chose s'il y a un bris de précondition)

Lisa Lippincott explique que c'est pour cette raison qu'on ouvre à porte à ce qu'une précondition ou une postcondition soit vérifiée deux fois, parfois. Elle dit déjà le faire dans son code, par exemple lors d'un appel système (elle valide ses paramètres pour déboguer son code, mais le noyau valide assurément ses intrants aussi). Elle rappelle que ce n'est pas une situation qu'on rencontre ailleurs : par exemple, un if ne sera pas testé deux fois par test. Elle examine la situation avec les fonctions virtuelles, où l'appelant peut avoir des préconditions et des postconfitions distinctes de l'appelé (la perspective de l'appelant et de l'appelé est doublement importante)

Lisa Lippincott dit qu'il peut arriver que les préconditions de la classe de base soient satisfaites (point de vue de l'appelant) mais que celles de la classe dérivée ne le soit pas (point de vue de l'appelé). C'est au fond un enjeu de substitutabilité de Liskov. C'est pas clair que le langage va vous sauver si vous faites ça. Elle montre qu'on pourrait injecter des protections de plus, mais notre choix de ne pas injecter d'information dans la vtbl pour indiquer qui est l'appelant rend cela improbable. Un appel dévirtualisé (inliné) semble plus prometteur... ça pourrait mener à une triple vérification des assertions, ramenant l'importance de ne rien faire de signifiant mais de dire quelque chose de signifiant

Lisa Lippincott : comment savoir si on dit quelque chose de signifiant? Quand on place une assertion dans le code source, il faut se souvenir qu'un échec d'assertion dans du vieux code est probablement la faute de l'assertion (si le code est vieux, il est probablement stable... mais on peut tout de même trouver de vieux bogues parfois!). Comment savoir si une assertion fait quelque chose de signifiant? Après tout, « signifiant » est probablement dans la tête de la programmeuse ou du programmeur... Un truc est de vérifier les assertions à l'entrée et leur répétition. Une assertion qui fait quelque chose de signifiant dérange souvent les autres assertions

Lisa Lippincott dit que les contrats sont le language feature le plus « cubiste » de C++. Ça dit quelque chose à partir de plusieurs perspectives

Pablo Halpern : comment caractériser un mode où le contrat est un truc qu'on veut vérifier occasionnellement, par exemple une fois sur 1000 quand on a un peu de temps à notre disposition?

Lisa Lippincott : notre proposition permet cela, mais ça risque de se faire de manière moins « mainstream » car c'est plus niché

Q : comment tester les contrats sur un std::function?

Lisa Lippincott : de manière générale, les implémenteurs peuvent appliquer les contrats sur les fonctions de la bibliothèque standard, mais ce n'est pas requis. Un implémenteur peut déclencher un contract violation handler de manière as if s'il y a un bris de précondition cas un tel bris est du comportement indéfini

Q : est-ce que les contrats peuvent éliminer le recours à assert()?

Lisa Lippincott : on a pre, post et contract_assert() qui est a bien des points de vue une version améliorée de assert(), alors oui c'est une possibilité

Q : l'appelant ne sait pas si une fonction est inlinée...

Lisa Lippincott : le compilateur qui compile l'appelant connaît sa situation, le compilateur qui compile l'appelé connaît sa condition. Il y a toujours quelqu'un qui sait...

Q : est-ce que sur le plan syntaxique, les signatures vont devenir très larges?

Lisa Lippincott : ça ne change pas les signatures, mais ça change les déclarations. Ça va impacter les .h

Madeline Schneider : peut-on déclarer un contrat et le réutiliser à plusieurs endroits?

Lisa Lippincott : non pour le contrat entier, mais on peut avoir un prédicat et l'appeler dans plusieurs préconditions par exemple

Madeline Schneider : quelle est l'ABI qui a des ennuis avec les contrats?

Lisa Lippincott : je ne veux pas donner de noms :)

Q : peut-on activer des contrats sur des groupes de fonctions?

Lisa Lippincott : on pourra les activer et les désactiver par unité de traduction, à tout le moins

Q : la fin n'appelle pas nécessairement std::terminate(). Quel est le plan?

Lisa Lippincott : ça a changé plusieurs fois. Les implémenteurs veulent de la flexibilité. Faudrait pas que votre code dépende du mode de terminaison (si tu dois en dépendre, écris ton propre contract violation handler, mais c'est une mauvaise idée de dépendre de cela de toute manière). Idéalement, utiliser quick_enforce!

Alex Dathskovski – To Int or to UInt, This is the Question

Alex Dathskovski fait un peu d'autopromotion puis nous indique que ce sera plus un « rant » qu'une présentation. On a trop de types entiers selon lui

Alex Dathskovski cite Bjarne Stroustrup qui prétend qu'on devrait utiliser int la plupart du temps, puis Dave Weiler qui prétend que les entiers non-signés devraient être plus populaires que les contreparties signées. Il dit que tous ses exemples compilent pour x86.

Alex Dathskovski montre deux fonctions qui font (a+b)/2 et demande si la version signée est meilleure que la version non-signée ou si l'inverse s'avère. Il compare le code généré dans les deux cas. La version non-signée est pas mal plus longue (pas clair qu'elle soit plus lente; les différences ne sont pas énormes). Il offre une analyse qui tient compte du pipeline interne du processeur et de la latence induite (la division par deux est reconnue comme un shift-right par le compilateur). C'est une belle explication. Pour ce qui est de la différence entre la versions signée et la version non-signée, il y a un enjeu avec les débordements qui sont définis sur les entiers non-signés et indéfinis sur les entiers signés. Il distingue SAR (shift arithmetical right) et SLR (shift logical right); il y a une petite nuance qui fait que SAR est préférable pour un entier signé (c'est un enjeu d'arrondi)

(un débat s'installe entre le présentateur et un membre de l'audience; il y a un désaccord entre les deux sur ce qui se passe dans cet exemple)

Alex Dathskovski parle ensuite d'opérations à signes mixtes (il additionne deux int8_t et retourne auto alors il y a promotion vers int, puis il additionne deux uint8_t et retourne auto ce qui impacte les résultats...). Il procède ensuite avec un int64_t et un uint64_t... Les règles de C sont déplaisantes

Alex Dathskovski fait ensuite un diatribe sur std::size_t et ssize_t (qui est POSIX, pas C++). On a des littéraux uz et z avec C++23.

Alex Dathskovski passe ensuite à une série arithmétique, et fait une sommation (une avec entiers signés, l'autre avec entiers non-signés). La version signée est bien meilleure que la version non-signée dans ce cas... car la version signée est du comportement indéfini, ce que le compilateur optimise agressivement, alors que la version non-signée doit respecter les règles. Faut pas faire de comportement indéfini, même pour aller vite! Il recommande d'utiliser des compilateurs plus récents, car ceux-ci optimisent mieux... Avec un clang récent, les deux ont essentiellement la même vitesse à l'exécution

Alex Dathskovski aborde la question des int_fastN_t et uint_fastN_t (il dit que ça fait une différence). Il parle de std::make_signed<T> et std::make_unsigned<T>, des traits fort utiles, puis std::cmp_equal() et ses amis. Il donne quelques conseils conformes à sa proposition (éviter auto quand on ne sait pas ce qu'on fait; préférer les types forts; ce genr de truc).

Daniel Hanson – Linear Algebra with The Eigen C++ Library

Daniel Hanson situe cette présentation comme visant à résoudre des programmes avec Eigen et avec stdBLAS de C++26. Il prend soin d'expliquer qu'il n'est pas affilié à Eigen même s'il s'en sert dans sa pratique

Daniel Hanson commence son discours en 1998. Il fait un gag sur 2001 odyssée de l'espace qui nous fait bien rire. C++ monte en popularité, en particulier dans le monde de la finance. À l'époque, pour faire des calculs matriciels, il fallait soit écrire ses propres classes, soit investir dans une bibliothèque commerciale... Soit utiliser Fortran

Daniel Hanson situe Boost uBLAS (novembre 2002). BLAS signifie « Basic Linear Algebra Subroutines » et vient du monde Fortran. Performances raisonnables, mais il manquait des trucs comme la décomposition de matrices. La plus récente version remonte à 2008. Eigen est arrivé en 2006, Armadillo en 2009, Blaze (par Klaus Iglberger) en 2012... La plupart sont exprimées sous forme d'Expression Templates

Daniel Hanson en arrive à aujourd'hui. C++23 nous amène std::mdspan ce qui est un gros pas en avant et permet d'offrir une vue multidimensionnelle sur un substrat unidimensionnel contigu en mémoire, incluant std::vector, Eigen::VectorXd et std::mdarray de C++26. Aussi, stdBLAS nous arrivera avec C++26.

(le pauvre Daniel Hanson a le nez qui coule; je le comprends, l'air est très sec et je suis « amanché » comme lui depuis deux jours)

Daniel Hanson présente ensuite Eigen et retrace l'histoire de cette bibliothèque. On parle d'une bibliothèque Header-Only (il explique un peu la structure du point de vue de Eigen::Matrix). L'approche de nommage est aussi expliquée. Il donne des exemples avec Eigen::MatrixXd (il y a des noms raccourcis pour les cas communs comme une 3x3 de float). Faut faire attention car les données sont entrées row-major mais entreposées column-major. Ils surchargent l'opérateur , pour l'initialisation. L'opérateur * sur des matrices implémente le produit matriciel (il y a d'autres types si on souhaite une multiplication élément par élément; on peut aussi multiplier une matrice par un scalaire). L'expression u.dot(v) est le dot-product(u,v) (on peut aussi utiliser std::inner_product() évidemment)

Daniel Hanson explique que les Eigen::Vector interopèrent bien avec les Ranges et les algorithmes standards. Il donne ensuite quelques exemples, par exemple une décomposition de matrice, des calculs impliquant de la régression linéaire, etc. (c'est pas mon domaine!)

Daniel Hanson poursuit vers le présent en présentant stdBLAS et l'espace nomné std::linalg. Il résout des problènes similaires avec cette bilbiothèque, et en la faisant collaborer avec Eigen. En utilisant des mdspan, il se ramasse avec une matrice triangulaire « à l'envers » dû à des choix de représentation différents. Il montre comment contourner ce problème (ajouter un paramètre au constructeur du std::mdspan)

Daniel Hanson conclut sa courageuse présentation (physiquement, il ne va visiblement pas bien, ce qui impacte sa nervosité)

Daniel Hanson informe les gens de son livre qui sort bientôt :)

Q : puisque les compilateurs ont amélioré leurs optimisations, est-ce que les bibliothèques d'il y a quinze ou vingt ans sont encore capables de compétitionner?

Daniel Hanson : j'ai fait des expérimentations, et j'ai eu des résultats dramatiquement meilleurs sur une vieille machine à deux coeurs. Sur ma machine à huit coeurs ça paraît pas mal moins

Q : est-ce que Eigen interface bien avec Fortran?

Daniel Hanson : pas sûr, c'est une bibliothèque C++

Q : est-ce que BLAS et Eigen vont être mis à jour pour utiliser stdBLAS quand ce sera disponible?

Daniel Hanson : je ne sais pas, mais au mieux de ma connaissance la réponse est non

Meet the Presenters Banquet

La réception était très agréable comme toujours. Les présentateurs comme moi avaient des tables assignées, et les gens qui avaient payé pour bavarder avec nous s'assoyaient là où elles ou ils en avaient envie. L'autre présentateur à ma table était Victor Ciura de Microsoft, un ami qui était dans une de mes classes en 2017 et qui vit maintenant à Prague. Il travaillait sur Visual Studio jusqu'à tout récemment.

Nos convives étaient quelqu'un qui travaille chez Amazon sur des drones mais est originalement de Toronto, quelqu'un qui donne dans la finance (le high-frequency trading), deux qui donnent dans l'aérospatiale, un qui écrit du logiciel pour suveiller l'état de câbles (si j'ai bien compris; dans une grande salle avec beaucoup de bruit, on en manque parfois des bouts)... J'espère ne pas en avoir oublié. Tous gentils et intéressants.

L'entrée était une belle salade colorée avec vinaigrette balsamique. Le pain était en une sorte de pâte de pretzel un peu salée avec un beurre aux herbes. Le plat principal était fait de riz brun, brocolini grillé, steak et saumon (très bien dans l'ensemble). Le dessert était une mousse au chocolat en forme de dôme avec un peu de fruits frais. Le tout avec vin et café. Le service était excellent.

Michael Caisse – Lightning Talks

Michael Caisse prend la parole, fait quelques blagues et cède sa place :

• Cassio Neri - « Saturday is coming faster, Part II - The magic is revealed » parle de la suite de sa présentation d'hier, en expliquant sa technique. C'est amusant et très clair, et ça passe par des nombres octaux (c'est pas mal plus clair que les constantes magiques d'hier!)
• Sakshi Verma - « C++ in the Cloud, One NIF at a Time with Elixir » parle de son travail avec le langage Elixir, où tout allait bien jusqu'à ce qu'elle ait besoin de parler au matériel... C'est une présentation sur l'interopérabilité entre ces langages (NIF est probablement « native interface »)
• Shivam Bairolyia - « Remote Execution Caching Compiler (RECC) » parle de l'accélération des temps de compilation à travers un outil développé chez Bloomberg. C'est intéressant : les compilations des uns accélèrent les compilations des autres
• Ali Almutawa Jr - « ... » dit qu'il voulait parler de « ... » mais qu'il a attrapé son air quand il a vu que quelqu'un a fait la même chose hier! Alors il y va d'une autre approche (qui fait un peu peur) pour écrire une fonction avec beaucoup, beaucoup de ponctuation...
• Emily Durie-Johnson - « Coding Like Your Life Depends on It » parle de l'écriture de logiciel pour assister des chirurgies au cerveau, et du processus pour assurer la qualité de ce logiciel (pas vraiment le droit à l'erreur, mettons). Écrire du code compréhensible est une priorité dans ce domaine
• Steven Arellano - « A Primer On Initialization » parle de... l'initialisation en C++, un sujet tellement simple... (il y a des trucs dont il va falloir lui parler, cela dit, parce qu'il confond UB et des banalités)
• Tyler - « How I Found the Time to Learn Emacs, Come with me » parle de... Rust? Parce que depuis qu'il compile avec le Build System de Rust, il a le temps d'apprendre Emacs :)
• Elizabeth Harasimiw - « When Computers Can't Math » parle de ... nombres à virgule flottante, et du plaisir de ce qui survient quand on calcule avec eux
• Conor Spilsbury - « From Macro to Micro » parle de l'analyse de données avec du bruit suspect. Il regarde les nombres et voit... des premiers. Hum, hash table... :)
• Andreas Weis - « Amortized O(1) Complexity » parle de l'historique de cette idée, qu'on ne trouve pas partout mais qui est importante pour nous. Il produit une analogie avec le coût monétaire d'une opération. Ça fonctionne! Il prend ensuite l'exemple de O(1) amorti sur un views::filter... Sa conclusion est pertinente : O(n) avec mémoisation n'est pas O(1) amorti
• Christopher Taylor - « ChpIX: Bridging Chapel and C++ for Enhanced Asynchronous Many-Task Programming » parle de Chapel, une déclinaison de C++ pour High-Performance Computing
• Ben Boeckel - « Whas does a CMake developer want from CMake? » parle de ses souhaits : des types (il n'a que des string et des listes!), des noms de variables raisonnables, une meilleure génération de code, de meilleures générations de Makefiles, des File Sets pour des tas de trucs, et des Declarative Inputs
• Braden Ganetsky - « Brainplus: A user experience » parle d'un parser generator inspiré de brainf*ck (je suppose) et utilisant + à toutes les sauces
• Scott Dixon - « Using PMR in embedded systems for functional safety » parle d'allocateurs PMR dans le contexte de systèmes embarqués, particulièrement celui des drones
• Alex H. Mann - « Just the Cliff Notes: A Mentee Adventure » parle de son expérience avec un mentor, et de son aventure d'inclusion. Elle recommande d'offrir du mentorat à des gens différents de soi
• Ben Deane - « What LLMs can't ever do ... and btw Emacs is awesome » parle de mots croisés cryptiques et d'indices pervers. ChatGPT est moins bon à ça que des programmeuses et des programmeurs :)

Michael Caisse ferme les livres. On a fini avec un léger retard, mais c'était amusant!