À propos de CppNorth 2022

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

Kate Gregory – Am I a Good Programmer

Kate Gregory est visiblement ravie de présenter un Keynote à Toronto. Elle vient de la région et dit ne pas avoir présenté à Toronto depuis au moins une décennie. Elle en profite pour demander combien de gens présents en sont à leur première conférence et... il y en a beaucoup! (à l'oeil, un tiers peut-être des quelques centaines de gens présents).

Kate Gregory parle de l'expérience chercher un problème pendant des heures pour s'apercevoir qu'il s'agit d'une faute typographique. Elle cible ensuite le mot Programmer (au sens anglais du terme), et du mot Good comme dans Good Programmer (pas comme dans Good Dog, et pas comme dans Great Programmer). Enfin, elle cible le « I » de « Am I... » et indique que le titre est exprimé au présent.

Kate Gregory parle du Dunning-Kruger Effect, et dit que ça ne s'applique pas à toutes les aptitudes. Elle enchaîne avec le syndrome de l'imposteur. Son schéma est très joli, d'ailleurs. Elle discute de l'importance d'apprendre et du lien avec ce syndrome, et mentionne qu'apprendre n'a pas nécessairement à impliquer de l'inconfort.

Kate Gregory demande si les programmeuses et les programmeurs qui sont bons ne sont pas simplement celles et ceux qui veulent l'être et qui se préoccupent de le devenir. Elle dit que ça ne suffit pas nécessairement; il existe de mauvais programmeurs, c'est vérifiable empiriquement. Il y a des gens (beaucoup?) qui feraient mieux dans un autre travail, manifestement. Il y en a même qui veulent être de bonnes programmeuses et de bons programmeurs mais qui n'y arriveront pas.

Kate Gregory aborde la question des « non-métriques » de qualité : pour qui on travaille, le temps durant lequel on a été au boulot, le code produit dans des dépôts publics, l'âge et l'expérience... même des diplômes. Alors comment savoir? Elle suggère de poser trois questions :

• Est-ce qu'on parvient à éviter ou à réduire l'impact des pires catastrophes?
• Est-ce que les autres souhaitent notre conseil, et reviennent pour en avoir d'autres?
• Est-ce qu'on aime faire ce qu'on fait?

Kate Gregory explique ces questions :

• Pour les catastrophes, elle ne parle pas de détruire une base de données (il devrait y avoir des copies de sauvegarde) ou de perdre son emploi (ça peut dépendre de bien des conditions), mais bien de créer quelque chose d'impossible à entretenir ou de travailler pendant des mois à partir de suppositions qui sont fausses, ou encore d'oublier de tester quelque chose d'essentiel avant de livrer un programme (elle a une chic anecdote à ce sujet). Elle ajoute le fait d'abandonner un projet à moitié fait
• Pour les conseils, ça peut se faire sur une base individuelle ou pas, mais le fait que les gens savent qu'il est possible de venir à notre rencontre est un signe. Aussi, est-ce que les gens appliquent ces conseils? Et reviennent-ils pour d'autres conseils par la suite? Kate Gregory mentionne au passage le courtoisie de dire merci
• Enfin, pour le plaisir (qui est essentiel), est-ce quelque chose que l'on fait autant par plaisir que pour un salaire? On peut aussi regarder le code pour essayer de voir s'il a été écrit par quelqu'un d'heureux 🙂 Et on peut jeter un coup d'oeil à notre curriculum vitae pour voir s'il évoque le bonheur

Kate Gregory poursuit avec l'enjeu de devenir meilleur(e), car ça ce fait (pas de surprises : pratique, lire, aller aux colloques ou regarder les présentations en-ligne, etc.). Elle propose des ressources. Évidemment, faut en faire pour comprendre!

Kate Gregory aborde la question de l'investissement personnel, d'être préoccupé par la qualité, le design, le nommage, l'entretien... Viser la qualité de la production est un signe de progression. Écrire des bibliothèques mène aussi dans cette direction. Mesurer sa propre progression ou  la progression de sa propre production est un autre signe.

Kate Gregory ajoute (c'est important) qu'un autre marqueur clé est se préoccuper du bien-être des autres programmeuses et programmeurs. Enseigner, partager, encourager, offrir du mentorat, etc.

Titus Winters : je comprends qu'apprendre fait partir du travail. Comment en convaincre son employeur?

Kate Gregory : je ne sais pas, mais une suggestion serait de libérer un peu de temps (p. ex. : deux heures par semaine?) où on peut indiquer « apprentissage » sur la feuille de temps. Il me semble que ça peut aider à la rétention des employé(e)s.

Daisy Hollman : j'entends que certains devraient répondre « non » mais pensent que « oui » et que l'inverse est vrai...

Kate Gregory : on peut mettre les gens en contact les uns avec les autres et amener une prise de conscience. Notez aussi que pour certaines personnes, ne pas aimer le travail est une conséquence d'un environnement de travail toxique...

Mike Daum : pour suivre tes conseils, il faut un certain investissement émotif. Comment les séniors peuvent-elles ou peuvent-ils aider?

Kate Gregory : les séniors peuvent encourager. Une chose qu'on doit éviter est dire que « c'est un jeu d'enfant » à un(e) collègue en difficulté.

Q : un ingrédient essentiel pour être une bonne programmeuse ou un bon programmeur selon moi est communiquer. Plusieurs ont une excellence technique et ne communiquent pas efficacement; leur contribution se perd avec le temps

Kate Gregory : on peut faire un bon boulot isolé dans une pièce, mais aujourd'hui, la communcation est essentielle, on ne peut pas y échapper...

Patrice Roy – Programming for Warm Days: Avoiding Dangerous Conversions

J'ai offert de dépanner les organisateurs parce que Björn Fahller n'a pas pu se rendre au pays (les aéroports sont tellement chaotiques ces jours-ci...), et j'ai présenté une version contemporaine de ../Divers--cplusplus/Implementer-changement-referentiel.html inspiré par une question de ma classe des derniers jours.

Il y avait plus de gens que j'aurais pensé pour une présentation « surprise » comme celle-ci (la salle était bien remplie), et il y a eu de l'interaction, des questions et du plaisir. Ce fut bien agréable.

Jason Turner – The Power of Compile-Time Resources

Jason Turner demande qui a été un invité à CppCast. À peu près 20% des mains se lèvent. Par la suite, il se présente. Jason Turner est toujours un excellent présentateur, très dynamique et très interactif.

Jason Turner rappelle les présentations du passé qu'il a faites sur constexpr (la plupart sont excellentes). Plusieurs portent sur des convertisseurs à JSON. Il dit en être à 28 vidéos sur constexpr... et que celle d'aujourd'hui pourrait être la dernière (les gens font « Oooooh »)

Jason Turner revient sur le problème de traiter du JSON à la compilation et se dit triste qu'on n'ait pas encore std::embed(). Il sonde la salle et ça semble être un besoin (plusieurs ont des fichiers de configuration connus à la compilation).

Jason Turner rappelle son travail sur json2cpp et ce que ça fait. Il souhaite éviter le runtime parsing des fichiers JSON et profiter du traitement dès la compilation. Son outil est compatible avec nlohmann::json qui semble être populaire. Il montre comment il réalise un « Compiler Firewall » pour isoler l'implémentation du code client, et en profite pour expliquer la différence entre inline constexpr et static constexpr.

Jason Turner trace la différence entre travailler à la compilation et ne pas travailler à l'exécution. Il se questionne sur ce qu'on fait en général à la compilation.

Jason Turner présente la taille des fichiers JSON qu'il doit traiter (plus de 9 Mo, plus de 155'000 objets), le tout connu à la compilation, et utilisé une seule fois à l'exécution. C'est un fichier JSON Schema utilisé pour valider un fichier .json consommé au démarrage. Le format binaire est CBOR et il faut le traiter au à l'exécution. Étrangement, extraire le CBOR du binaire a augmenté la taille de ce binaire. La raison est que la plupart des nombres ont une petite représentation texte (p. ex. : "4.2") et prennent plus de place en format binaire. La consommation de mémoire vive décroît par contre (moins d'allocations) et compense (et même plus!).

Jason Turner montre l'utilité de throw dans une fonction consteval : si le code te mène là, le code ne compile pas! Il y a de la résistance dans la salle 🙂 Il enchaîne avec un exemple de configuration du matériel faite à la compilation (seule l'écriture sur les ports est faite à l'exécution). Un des principaux intérêts à mes yeux est le déplacement des erreurs à la compilation.

Jason Turner montre que pour les gens qui n'ont pas de fichiers JSON, un fichier de configuration avec une map constexpr est une option mais ça prend une map constexpr ou un équivalent. Il joue ensuite avec std::string et constexpr pour montrer les limites et les applications.

Jason Turner cite un Tweet de Ólafur Waage qui voulait générer rapidement des nombres aléatoires et montre une jolie petite solution.

Daisy Hollman défend le choix de lever une exception dans une fonction constexpr ou consteval en expliquant ce que cela signifie.

Jason Turner fait un plaidoyer pour un JIT de constexpr.

Daisy Hollman – Cute C++ Tricks (and what you can learn from them): part 2 of N

Daisy Hollman explique sa démarche dans cette série de présentations : identifer des trucs étranges, mais comprendre pourquoi pour s'améliorer. Elle annonce en particulier un truc très obscur qu'elle n'a jamais montré jusqu'ici. Elle mentionne aussi que certains mots comme Crazy comme dans I loved your crazy tricks... peuvent offenser.

Daisy Hollman recommande d'écrire du code qui ne surprend pas, alors que cette présentation sera délibérément faite de code qui surprend.

Daisy Hollman procède avec un truc qui montre qu'on peut utiliser throw ou assert dans une fonction constexpr, mais pas static_assert sur des particularités qui dépendent des paramètres de la fonction (une explication de ce qu'on peut faire avec constexpr suit). Un cas vilain est

constexpr int f(bool b) { return b? throw 3 : 0; }
constexpr int g() { return f(true); } // IFNDR car le pauvre compilateur ne peut pas connaître le contexte d'appel

... et Daisy Hollman montre que plusieurs implémentations de assert sont équivalentes à ce f(bool)!

Daisy Hollman poursuit en montrant comment il est possible de compter les membres d'un agrégat. Suffit d'essayer de le construire avec des objets qui se convertissent en n'importe quoi (des skeleton_key, mais limités aux déclarations pour être utilisés comme declval<T>())! Elle utilise des requires pour tester avec 0, 1, 2, ... paramètres en utilisant une λ générique sur un index_sequence, de même qu'un petit template charmant nommé template <class T, size_t Idx> using repeated_with = T; en utilisant repeated_with<skeleton_key, N> pour générer ses tests. Le concept ConstructibleWithN est ensuite présenté au complet. Un problème demeure car ConstructibleWithN<X,1> tend à passer dû aux constructeurs de copie et de mouvement implicites; un autre est les constructeurs qui acceptent un paramètre par référence sur un lvalue (le truc est d'avoir operator T&() et operatorT&&() mais pas operator T()). Un autre problème est que les types Move-Only ne passent pas (le processus de sélection des candidats considère les membres =delete!). Il se trouve que requires false fait un meilleur travail que =delete dans ce cas! (Titus Winters est stupéfait). Ajouter un const (donc operator T&() const) aide aussi... Ouf!

Daisy Hollman continue en ajoutant un AnyExcept<T> (skeleton_key qui teste tous les types sauf...). Ensuite, elle montre que ConstructibleWithN<T,N> doit s'accompagner d'une !ConstructibleWithN<T,N+1>

Daisy Hollman poursuit en montrant une sorte de réflexivité sur des agrégats. Elle présente ce qu'elle dit être le bout de code le plus épeurant qu'elle ait jamais vue. Elle évoque le texte « non-constant constant-expressions in C++ » dont on a beaucoup parlé à CWG à l'époque. C'est vraiment pervers (ça utilise les clauses requires et des fonctions friend pour créer des « compile-time type maps »).

Titus Winters – Software Engineering Languages

Titus Winters aborde l'enjeu de distinguer Software Engineering et Programming, et se demande si certains langages sont meilleurs pour l'un ou pour l'autre. Il se questionne sur les propriétés que devrait avoir un Software Engineering Language. Il utilisera Computing Language à titre de terme général.

Titus Winters présente le Software Engineering comme le Multi-Person construction of Multi-version programs (Dave Parnas, 1974), puis associe le concept à la durée de vie d'un programme (il place Programming à gauche, court terme, et Software Engineering à droite, décennies). Le temps est le super-vilain selon lui (il présente d'intéressants schémas, pensez à regarder la présentation quand elle sera disponible).

Titus Winters discute ensuite du moment pour insérer les tests et le suivi dans le processus de développement logiciel : plus haute fidélité si plus tard, mais moins cher si plus tôt. Entre autres, l'analyse statique et les systèmes de types plus solide aident beaucoup.

Titus Winters parle des propriétés des langages (lisibilité vs Writability; abstraction vs convention; collaboration ou contrôle individuel; statique ou dynamique). Certaines propriétés sont plus « multi-personnes » que les autres. Il essaie d'appliquer la théorie de la densité de l'information aux langages de programmation. Perl est très dense, mais peu lisible (Write-Only). C++ est beaucoup plus lisible. L'enjeu de la clarté suit (peut-on saisir rapidement ce que le code fait? Fait-il ce qu'il semble faire?), où C++ fait moins bien.

Titus Winters poursuit avec l'abstraction. Il critique les templates, aime mieux les concepts, mais note que c'est pas encore parfait. Il mentionne que les concepts n'ont pas de Fallback Mechanism (de comportement par défaut) alors que les méthodes virtuelles en ont. Pour la collaboration, il se dit d'avis que les modules sont un bon pas en avant. La distribution demeure un enjeu, surtout en comparant C++ avec Python ou Rust. De même, la capacité de refactorisation est essentielle pour le Software Engineering de même que pour celle de mise à jour (il questionne le support à très long terme du code du passé).

Titus Winters continue avec l'impact des mises à jour sur la syntaxe... et inversement. Ensuite, la taille des changements est discutée (c'est facile d'accepter une petite mise à jour, c'est coûteux d'accepter une mise à jour de quelques années). Les enjeux d'ABI jouent pour beaucoup. La contrepartie est la trifecta de stabilité, d'interopérabilité et de compatibilité... Pour le Software Engineering, la stabilité semble être un objectif, mais il y a des coûts.

Titus Winters présente l'idée de sélection de version minimale (au sens de « ce paquetage demande au moins cette version... » et dit que changer de numéro de version majeur, c'est démarrer un nouveau projet.

Titus Winters explique que Rust a un système de Global Testing qui fonctionne et dit que c'est une excellente idée. Semble que beaucoup de programmeuses et de programmeurs ne font toujours pas de tests, tous lamgages confondus.

Titus Winters discute de propriétés secondaires de langages : sécurité, incluant la capacité d'ajuster le langage quand un problème de sécurité survient. Évolution du matériel et diversité du matériel (C++ compile même sur WebAssembly maintenant, et nous avons des compilateurs C++ pour ordinateurs quantiques!). Efficacité dans l'utilisation des ressources, un problème qu'il présente comme significatif : par exemple, le coût du matériel dans un projet dépasse-t-il les coûts humains?

Titus Winters revient sur sa question initiale, à savoir si certains langages sont meilleurs pour le Software Engineering (il demande aux gens dans la salle s'ils veulent participer à un gros projet en Rust ou en Perl; le choix de Rust est presque universel). Il dit aimer Python pour les gros projets qui vivent longtemps. C++ a beaucoup de forces, mais sur certains aspect du Software Engineering il reste du travail à faire. Il pense que Go compétitionne plus avec Python qu'avec C++. Il lui semble possible de penser un langage axé sur le Software Engineering (Go et Rust sont sur la voie), mais ajoute qu'ignorer la masse considérable de code C++ existant serait périlleux. Tout de même, C++ est manifetement solide, ça se vérifie empiriquement.

Q : quand on est contractuel, c'est souvent le client qui choisit les outils...

Titus Winters oui. On n'a pas d'arbre de décision partagé des acteurs de l'industrie pour ce genre de décision. (un échange sur l'interopérabilité s'ensuit; C demeure pertinent ici)

Conor Hoekstra : quel est l'impact de la familiarité sur le succès d'un langage? (il parle de Perl, mais aussi des expressions régulières, et de Python qui ressemble à du pseudocode).

Titus Winters estime que c'est une question pertinente. Entre autres, enseigner les expressions régulières demande de la prudence, et trop de gens les utilisent incorrectement. C'est difficile de demander à des gens d'apprendre des langages complètement nouveaux. Les petits changements incrémentaux tendent à mieux passer...

Daisy Hollman : et qu'en est-il du sucre syntaxique?

Titus Winters : selon moi, si on est trop bavards, ça nuit à la compréhension. Faut trouver un point d'équilibre entre concision et verbosité. J'aimerais qu'om fasse plus de recherche sur la lisibilité des langages de programmation en tant qu'interfaces personne/ machine.

Movie Night: with Walter Brown

Walter Brown est merveilleux. Droits, permissions, raison d'être de la soirée.

Une petite vidéo sur la machine de Turing... en Lego (c'est drôle! Format publicitaire 🙂)

Programmer de la musique avec des dominos qui chutent, des balles, des blocs, des billes et des aimants (musique de Fantasia – Tchaîkovski)

Autre expérience, avec 5000 billes (je l'avais déjà vue celle-là), la Wintergator Marble Machine si je ne m'abuse

Pourquoi les ordinateurs ne sont-ils pas couverts par un brevet? Un documentaire avec John Vincent Atanasoff... Sa machine, la ABC (Atanasoff-Berry Computer), précède ENIAC. ENIAC avait un brevet qui appartenait à IBM, et Honeywell voulait produire des ordinateurs alors un avocat y a travaillé pendant cinq ans. L'avocat a démontré que ENIAC est venu après ABC et a brisé le brevet. Les documents légaux de ENIAC étaient cachés sous les gradins du stade de l'université de Pennsylvanie! Atanasoff explique que quatre aspects clés (unité logique, arithmétique binaire, électronique, mémoire vive) définissaient sa création : on y calculait avec des électrons, pas de la mécanique. Atanasoff a proposé son idée à IBM qui a refusé et travaillait sur une grosse bête, le Mark I, alors que la machine d'Atanasoff était la taille d'une table de travail. John Mauchly (co-inventeur de l'ENIAC avec John Presper Eckert) était un professeur associé qui travaillait sur des calculs météo avec un calculateur plus traditionnel, et John Vincent Atanasoff lui a expliqué son idée avant que ENIAC ne soit conçu. John Vincent Atanasoff était très gentil et très naïf : il leur a tout montré, incluant son manuscrit explicatif qu'ils ont copié (manuellement!) la nuit. Semble que chaque fois qu'on allumait ENIAC, les lumières de Philadelphie perdaient en intensité. Le brevet était entre les mains de Sperry Rand, techniquement, et IBM voulait négocier avec eux. Chose amusante : pour le procès, ce fut la première fois qu'un ordinateur fut utilisé pour conserver l'information utilisée... pour déterminer sa propre origine! Ils ont fini par trouver une lettre où Mauchly demandait la permission à Atanasoff d'utiliser ses idées... Ça a pas mal tué le brevet de ENIAC. La poursuite pour briser le brevet a duré cinq ans, et s'est terminée en 1973. John Vincent Atanasoff n'a pas beaucoup gagné de renommée car le procès (énorme!) s'est conclu quand le Watergate dominait dans les médias. On entend un discours de John Vincent Atanasoff en 1981 et c'est plein de reconnaissance et de constructif.

Walter Brown donne quelques mots sur ce qui est arrivé au ABC. Il connaissait personnellement des individus impliqués. La personne qui a désassemblé l'ABC était professeur quand il était étudiant. C'est un moment émotif. Il dit ne jamais avoir connu Clifford Berry, qui est mort (mystérieusement) assez jeune, et Walter Brown dit qu'on ne sait pas comment il est mort encore aujourd'hui. Le ABC contenait la première RAM. Ça faisait encore une opération chaque 15 secondes. Walter Brown dit qu'un des plus grands moments de sa carrière était en 1981 quand il a pu offrir un doctorat honorifique à John Vincent Atanasoff 🙂

Walter Brown nous offre quelques mots sur Grace Hopper, qui n'a pas pu entrer dans la marine car il lui manquait... 15 livres de poids. Elle a écrit, en plus de COBOL, le premier éditeur de liens (Linker) et le premier Loader. On a droit à une chic petite vidéo d'elle, qui relate le premier bogue. On a une photo! On fait le tour de ce qu'elle a fait... C'est gênant pour les pauvres mortels que nous sommes! Il y a même un navire de guerre nommé le USS Hopper, le Amazing Grace 🙂

On a ensuite un petit clip audio par The Frantics (Frantic Times) sur les chiffres romains (Roman Numerals).

(brève pause; je bavarde avec Francis Lemaire et Rémi Drolet qui me montre des photos de son premier enfant 🙂)

On examine I'm my own Grandpa, une vidéo sur la théorie des graphes. On se croirait dans Dark 🙂

Ensuite, on a une vidéo sur l'origine de Bluetooth. On parle de Hedy Lamarr, sexe symbole... et inventrice. Elle a entre autres inventé les feux de circulation... et un système de communication secret! Son idée était tellement en avant de son temps qu'elle a été rejetée plusieurs fois, puis implémentée dans des milieux miltaires, et sert désormais entre autres dans les GPS.

Le film suivant remonte aux années '80 et porte sur le tri. On examine le tri par insertion, le tri par insertion avec recherche binaire, puis Shellsort, puis les Exchange Sorts (incluant le tri à bulles, le Shakersort -- intéressant- -- et le Quicksort), puis les tris par sélection (Straight Selection, Tree Selection -- joli! -- puis HeapSort. On blague à propos des tris quadratiques même dans la vidéo.

Walter Brown termine en nous invitant à ses (excellentes!) présentations, puis présente une dernière vidéo de percussions générées de manière procédurale.

On termine vers 22 h 22

Chandler Carruth – Science experiment time!

Chandler Carruth dit que son vrai titre est « C++: What Comes Next? ». Il dit ne pas savoir, mais pense qu'on devrait le savoir. C++ venait après C, Kotlin après Java, mais après C++...?

Chandler Carruth rappelle que les objectifs du langage sont listés dans p2137 mais que C++ n'atteint pas encore ses propres objectifs. Pourquoi? Selon lui, la raison est qu'on accumule trop de dettes techniques. C'était la bonne décision d'accumuler tout cela (le bagage de C en particulier) et de prioriser le support du code existant, mais ça nous amène à des trucs comme co_return par exemple. Ces choix nous empêchent de corriger les problèmes.

Chandler Carruth le processus d'évolution du langage ralentit aussi l'introduction d'améliorations au langage. Le processus ISO a du bon, mais son objectif est de tenir compte des compagnies et des pays.

Chandler Carruth : quelles sont nos options? Les langages avec ramasse-miettes ont des bons côtés, mais ont des coûts qui ne sont pas acceptables pour certains. Rust, peut-être? C'est très intéressant, et pourquoi pas si ça convient à vos besoins, mais si on a un écosystème C++ très étendu, migrer à Rust entraînera des coûts monstrueux.

Chandler Carruth compare d'autres évolutions (C -> C++, JavaScript -> TypeScript, Java -> Kotlin, Objective-C -> Swift) à ce qu'il envisage. Kotlin lui semble inspirant car l'intégration avec Java est naturelle. Dans tous les cas, les « lamgages successeurs » ont été pensés en conséquence de leurs objectifs.

Chandler Carruth présente des objectifs pour un tel langage. Quand c'est un sur-ensemble, le langage antérieur est pleinement supporté, mais l'approche Kotlin lui semble plus intéressante. Il a donc commencé à travailler sur le langage Carbon, un successeur à C++ conçu pour cette fin. Les clés sont l'interopérabilité, en se permettant de ne pas apporter la dette technique; la migration, qui permet de nettoyer certains irritants; et un modèle d'évolution du langage à l'aide d'outils.

Chandler Carruth présente ensuite le langage Carbon. Il parle de nettoyer la grammaire en ajoutant des mots clés introduisant des mots (fn, var, ...) pour que ce soit plus près de Rust ou de Go. Des paramètres intrants simples. Des pointeurs pour fins de mutations indirectes. Utiliser des expressions pour nommer des types (c'est intéressant; à explorer). Utiliser le paquetage comme namespace racine. Importer les API à travers les noms de paquetages. Des membres publics par défaut (on peut les rendre privés explicitement). Un this explicite dans les fonctions membres comme Python, le vieux C++ ou Deducing *this; muter l'instance active se fait par un pointeur sur soi passé en paramètre puisque les paramètres sont passés par valeur. Héritage simple seulement, et classes final par défaut. Des génériques qui vérifient les définitions (c'est un truc à la C#, avec interfaces intrusives; j'aime pas vraiment, ayant vu les limites à l'usage). Des types qui implémentent explicitement les interfaces (idem). Bonne nouvelle par contre : les API sont extensibles de manière externe. Et ainsi de suite.

Chandler Carruth poursuit sur le point (important!) de l'interopérabilité. Une ligne import Cpp library "abc.h"; active le compilateur C++, génère un module qui est ensuite navigué pour générer la représentation Carbon, et l'inverse est aussi vrai (#include "abc.carbon.h").

Chandler Carruth : à propos de la migration et du processus, on veut créer une communauté et une culture. C'est une bonne idée de mettre d'office à l'avant-scène les bases d'une communauté agréable et inclusive. On veut des outils et un écosystème, des tutoriels, etc. et un package manager! Éventuellement 🙂 Le modèle visé est à code ouvert, contemporain. La gouvernance reposerait sur un groupe de trois « leads » (Chandler Carruth, Kate Gregory, Richard Smith) avec plusieurs membres connus de la communauté C++.

Chandler Carruth poursuit avec une démo « live » sur... Carbon Explorer. Il a des if-expressions. L'outil vient avec un outil de trace pour explorer le code généré. Ça marche déjà dans Compiler Explorer.

Chandler Carruth revient sur la question de ce qui suit pour C++. Après tout, C++ survivra longtemps. Est-ce que Carbon fera partie des suites? Chandler Carruth ne sait pas. Il fait un appel à la communauté.

Chandler Carruth appelle les deux autres « leads » pour une discussion « live ».

Q : comment compétitionner avec un langage qui a autant de vécu?

Chandler Carruth : on ne compétitionnera pas. On cherche à s'intégrer et à ouvrir des portes.

Q : pourquoi utiliserais-je Carbon?

Chandler Carruth : entre autres, on gagne des génériques vérifiées

Richard Smith : on peut faire avancer les choses plus rapidement en se défaisant du comité

Q : qu'en est-il du Memory Safety, que Rust offre?

Chandler Carruth : c'est le point de départ de Rust. Le nôtre est interopérabilité avec C++ qui n'est pas Memory-Safe. On a des collègues qui essaient de rapprocher C++ et Rust sur d'autres projets. C'est un objectif à long terme.

Q : pourra-t-on réutiliser des outils faits pour C++ avec Carbon?

Richard Smith : pas directement, non, du moins pas à court terme.

Guy Davidson : C++ n'a pas de réflexivité. Quels sont les plans pour Carbon?

Chandler Carruth : on y pense beaucoup mais on n'a pas de plans clairs encore. Je ne vois pas ça comme un obstacle. Le recours à un compilateur C++ pour fins d'interopérabilité devrait nous aider beaucoup (la migration me semble plus difficile que l'interopérabilité ici)

Q : qu'advient-il des enjeux de licence (CLA)?

Chandler Carruth : on transfèrera éventuellement

Q : d'où viennent vos inspirations?

Chandler Carruth : C++, bien sûr.

Richard Smith : Rust et des langages semblables, Zig. Haskell.

Chandler Carruth : Kotlin (membres publics par défaut)

Richard Smith : Swift pour les génériques.

Q : j'aime que passer par valeur et par référence-vers-const soit la même chose. Comment gérer l'aliasing?

Chandler Carruth : c'est un défi! Mais on n'a pas vu beaucoup de bogues en pratique quand on a fait des tests.

Q : j'aime que les entités mutables soient des pointeurs. Que faire des pointeurs nuls?

Chandler Carruth : on corrige le bogue et on les rend non-incrémentables. Un pointeur nul peut devenir un optional<pointeur>

Q : que ferez-vous avec l'évolution et les risques de bris d'ABI?

Richard Smith : on veut éviter d'avoir un ABI fixe pour Carbon. Pour les modules compilés séparément, on vise une ABI stable. On veut des outils pour des changements porteurs de conséquences comme modifier une interface

Kate Gregory : avoir des outils nous aidera à survivre aux bris.

Q : et les bibliothèques tierces qui peuvent ne pas avoir les mêmes outils?

Chandler Carruth : il y a le cas des bibliothèques écrites en C++ bien sûr. Avoir la possibilité d'expliciter une ABI est ce qu'on explore.

Q : et à propos des Build Systems? J'ai vu que vous utilisiez Basel...

Chandler Carruth : on l'utilise parce que ça facilite les tests pour nous, particulièrement les Fuzz Testings, mais on n'est pas en train de choisir un Build System. On vise un modèle qui sied aux Build Systems existants

Q : pour l'intéropérabilité et la migration avec C++, y a-t-il des limites?

Richard Smith : on pense supporter C++ 17

Guy Davidson : à propos de la gouvernance, ça ressemble à un petit groupe de dictateurs 🙂

Kate Gregory : on a pensé avoir un seul gentil dictateur 🙂 On est trois pour débuter

Chandler Carruth : on peut penser à un système de rotation. On a éliminé un modèle stratifié d'acceptation, où il fallait passer certaines seuils (trop lent à nos yeux). On veut bouger rapidement

Q : pourquoi choisir un modèle de transition reposant sur des outils? Il arrive qu'un projet soit stable et fonctionne, et qu'on ne souhaite plus le modifier. Des Epochs?

Chandler Carruth : un système de versionnage comme les Epochs peut être bien. On réfléchit encore à ces aspects. La gestion du changement est une de nos préoccupations.

Richard Powell : comment peut-on contribuer?

Chandler Carruth montre le github et le discord

Q : pourquoi ne pas simplement chercher à améliorer C++?

Chandler Carruth : on n'arrêtera pas de chercher à améliorer C++; on essaie de faire des changements plus radicaux et plus rapides par un autre chemin.

Kate Gregory : plusieurs ajustements sont pour les défauts du langage. Pour ça, fallait partir à neuf

Guy Davidson : vous parlez au fond d'un langage successeur à un langage successeur ici. A-t-on déjà vu un succès ici?

Chandler Carruth : Swift, qui suit Objective-C alors que celui-là suivait C

Richard Smith : plusieurs versions d'un même langage serait un autre exemple

Q : comment pensez-vous mettre la communauté en place?

Chandler Carruth : on travaille avec Céline Dedaj et on essaie de démarrer avec un solide code de conduite

Kate Gregory : on veut éliminer les éléments toxiques d'office

Q : il arrive qu'on doive passer par des intrinsèques. Avez-vous une vision ici?

Richard Smith : on n'a pas de plan en ce sens, mais on vise donner le plein contrôle de la machine

Chandler Carruth : on veut donner accès presque direct aux services du compilateur

Timur Doumler : une des forces de C++ est que nous avons plusieurs compilateurs sur une multitude de plateformes. Quelle partie de cet écosystème essayez-vous de couvrir?

Kate Gregory : je suis une « Windows Person » 🙂

Chandler Carruth : c'est une question à long terme. Avant d'aller là, faut voir si Carbon est ce qu'on veut pour le futur de C++.

Timur Doumler : à quel point Carbon dépend-il de Clang?

Richard Smith : pas vraiment

Guy Davidson : comment peut-on influencer la bibliothèque standard?

Richard Smith : on n'a pas de ligne claire encore

Kate Gregory : on est encore en train de choisir des mots clés 🙂

Q : visez-vous une implémentation opaque?

Chandler Carruth : notre chemin est d'avoir une couche très mince entre bibliothèques et le compilateur

Q : comment envisagez-vous la gestion de la complexité avec l'évolution?

Kate Gregory : le fait qu'on accepte de briser du code devrait nous aider. Même changer les défauts en cours de route devraient nous aider à gérer les surprises

Chandler Carruth : ce ne sera pas un langage simple car il nous faudra supporter les cas d'utilisation de C++

Daisy Hollman : sur Twitter, ça parle beaucoup de Carbon depuis 30 minutes, en particulier dans la communauté Rust

Q : changer des mots clés dans du code existant peut sembler déstabilisant. Comment trouver l'équilibre entre évolution et stabilité?

Chandler Carruth : on ne sait même pas encore si c'est une bonne idée, et si c'est une bonne idée, faudra parler avec les usagers et saisir leur opinion

Michael Daum : que ferez-vous avec le comportement indéfini dans le contexte de l'interopérabilité?

Chandler Carruth : on en veut le moins possible dans Carbon, mais pour le reste... On ne veut pas changer le code C++ qu'on appelle. Et si le code C++ contient du comportement indéfini, il est déjà brisé.

Richard Smith : on aimerait au moins pouvoir le diagnostiquer

Chandler Carruth présente des artisans de Carbon qui sont dans la salle. Certains sont des gens que je connais.

Tony Van Eerd – Value Oriented Programming. Part 1: you say you want to write a function

Tony Van Eerd commence avec une blague sur le recrutement. La musique semble être un thème ce matin, et il en va de même avec les références à Star Wars.

Tony Van Eerd dit qu'on veut en général écrire du code et régler des bogues, pas écrire des fonctions. Cela dit, il montre un exemple de cas où on doit couvrir un cas particulier et où on s'empêtre dans les détails. L'empêtrement se fait à travers le passage du temps, et on s'englue... Il introduit le mot « Complecting » en citant Rich Hickey et en examinant l'étymologie du mot. On s'empêtre parce que ça semble être la voie facile...

Tony Van Eerd dit avoir beaucoup réfléchi à la question « pourquoi le code complexe paraît-il si mal? » et sa conclusion est que c'est la voie de la facilité (la paresse, je dirais). Et il fait exactement ce que je fais avec mes étudiant(e)s : il transforme son commentaire en appel de fonction! Puis il remplace le commentaire pour expliquer la raison derrière la fonction (ou plus précisément : quelle serait la conséquence de ne pas poser ce geste).

Tony Van Eerd recommande de ne pas insérer de noms de types dans les noms de fonctions (il dit la même chose que moi; je vais faire regarder la vidéo à mes étudant(e)s).

Tony Van Eerd enchaîne avec un Koan. On s'amuse beaucoup. Mais la leçon est : si tu as besoin d'une fonction et si elle n'écrit pas, écris-la. Une fonction est une réponse à une question. Écris les fonctions que tu veux voir dans le monde.

Tony Van Eerd apporte un autre Koan. Adorable

Tony Van Eerd poursuit avec une discussion sur le choix des paramètres (passer à la fonction ce dont elle a besoin, pas plus, pas moins). C'est une bonne manière d'éviter de faire plus que nécessaire dans la fonction appelée. Il propose une approche à la Maurice Joyal (top-down, puis bottom-up, et on se rejoint au centre). Il propose KYSS : Keep Your Stuff* Separate (* : il y a des variantes ici)

Tony Van Eerd présente les valeurs comme ces entités dont on ne se préoccupe pas de l'identité et les objets comme ces entités pour lesquelles l'identité est importante. Ok, je peux vivre avec ça, même si c'est pas ma définition. Ça explique son recours au passage par référence pour les objets.

Tony Van Eerd discute de la valeur de la testabilité, et des conséquences de la mutabilité. Il suggère « separate calculating from doing » comme adage. Il donne un example basé sur un texte du Dr Seuss (une fonction StarOn(Sneetch&) de type void -- il présente les fonctions void comme des Code Smells... Bravo mon ami!). Les fonctions sans effet de bord (fonctions pures) se testent tellement mieux... une fonction pure est Thread-Safe par définition, et permet le raisonnement local.

Tony Van Eerd parle de « recherche récente » sur les sous-routines par un jeune nommé David Wheeler, qui aurait travaillé avec Bjarne Stroustrup (il m'a vu rire du gag; c'est un texte de 1951 et David Wheeler est le directeur de thèse de Bjarne Stroustrup). Le texte se nomme « The use of sub-routines in programmes »

Tony Van Eerd examine l'enjeu de déplacer une fonction globale et d'en faire une fonction membre, pour « épargner des paramètres », puis en profite pour discuter de niveaux d'abstraction. Petite pensée pour mes étudiant(e)s du DDJV qui s'empêtrent dans ces choix suspects année après année (les moteurs qu'elles ou ils utilisent font souvent les mêmes erreurs). Les fonctions (Free Functions) permettent le partage et évitent l'empêtrement! Tony Van Eerd rappelle que les classes sont faites de velcro : ce qu'on leur ajoute s'accumule à travers le temps... Les fonctions globales ne dépendent que de l'interface publique d'une classe, et sont moins sujettes à briser avec le passage du temps que les fonctions membres qui, elles, sont couplées avec l'implémentation.

Tony Van Eerd dit qu'on ne saura vraiment si du code est bon qu'avec le passage du temps, en voyant comment il survit. Évidemment, du bon code fonctionne, est efficace, s'entretient bien et permet d'écrire d'autre code (s'il rend le reste du code meilleur, en quelque sorte). Il rappelle aussi l'enjeu des invariants d'une classe : les fonctions membres sont nécessaires (faut parfois accéder à la représentation interne après tout) et il faut que ces accès soient faits dans le respect des invariants du type. Il rappelle que les quaternions en particulier ne devraient pas être modifiés une coordonnée à la fois, ils ont des invariants à maintenir.

Tony Van Eerd demande combien de fonctions sur des string existent : ℵ₀ ou un infini non-dénombrable? Sa réponse est... beaucoup. Combien devraient être des fonctions membres? Question réthorique...

Tony Van Eerd discute des paramètres sortants (moche) et du fait qu'on n'en a plus vraiment besoin dans que ça en général, sauf peut-être pour réutiliser de la mémoire dans une boucle, mais même là on peut écrire une fonction propre et une moins propre et faire en sorte que l'une appelle l'autre. Les fonctions pures sont plus débogables.

Tony Van Eerd poursuit avec une discussion des verbes dans les noms de fonctions (get ne devrait pas faire de travail, c'est pas le bon verbe).

Tony Van Eerd rapporte un cas où un collègue voulait transformer une λ en back_inserter : écrivez les fonctions que vous souhaitez voir dans le monde! Puis il montre quelques exemples de code réel... qui retournent void, ou prennent les mauvais paramètres.

On n'a pas de temps pour les questions, tristement...

Daisy Hollman : fais-tu confiance à tes usagers pour savoir quand ils ont besoin de vitesse?

Tony Van Eerd : non,  mais c'est pratique d'avoir une personne qui est capable de juger dans une équipe...

Q : comment encourager mes collègues et mes supérieurs à écrire des fonctions?

Tony Van Eerd : tu les attrapes a posteriori. Tu auras ta chance...

Arno Schödl – Why Iterators Got It All Wrong

Arno Schödl explique des problèmes qu'il voit dans le modèle ranges / itérateurs de C++, se basant en partie du passage par .base() sur le résultat de vues. Je ne suis pas convaincu par son argument (le maintien de la sémantique en « remontant » de niveaux de transformation ne me semble pas devoir être garantie), et son exemple de reverse_iterator est incorrect (il ne fonctionne qu'avec des random_access_iterator).

Arno Schödl propose de distinguer .base() et .border() pour des fruit de transformations comme lower_bound() ou upper_bound() où l'on cherche effectivement une frontière dans une séquence.

Arno Schödl critique aussi le recours à end(v) pour marquer l'échec d'une recherche. Il dit qu'il préférerait un concept de Border et un autre pour Element, et qu'on ne devrait pas pouvoir déréférencer un Border. Les output iterators sont des Border selon lui. Il liste ensuite les algorithmes retournant des itérateurs qui devraient à son avis retourner des Border. Il pense que Border devrait être Nullable

Arno Schödl propose de permettre aux fonctions sur des Ranges d'exprimer au point d'appel les règles quand à leur type de retour et au comportement de la fonction appelée

Walter Brown – Computing‿in‿the‿1960's

Walter Brown nous accueille avec sa dignité habituelle. Il va nous parler de ce dont il se souvient... Le matériel, les systèmes sur lesquels ils travaillaient, des anecdotes, etc. incluant des disques rigides de la taille d'une machine à laver.

Walter Brown présente une Punch Card et explique comment ça fonctionnait. La taille correspondait initialement à celle de la monnaie américaine pour faciliter le rangement. IBM avait breveté les trous rectangulaires! Semble qu'à la fin des années '50, les Punch Cards représentaient environ 20% des revenus d'IBM! Il nous montre une machine à trouer les Punch Cards. Une faute typographique et il fallait jeter la carte (irrécupérable). C'était aussi très inflammable alors il fallait être prudent en jetant les retailles (nommées chad). On a droit à une chouette démonstration. Il montre des trucs qui expliquent le recours à // comme DEBUG = TRUE // ESLAF = GUBED qui permettait d'alterner le mode en pivotant la carte! Les trous de / étaient à la même position des deux côtés. Il relate aussi des bogues reliés à des taches sur des cartes qui n'apparaissaient que dans certaines conditions météo...

Walter Brown nous présente un IBM 082 card sorter de 1949... Ouf! Ensuite, il nous rappelle que certaines machines étaient cablées pour des tâches spécifiques, avant l'arrivée de panneaux de contrôle en 1906 et de panneaux de contrôle amovibles en 1920. On parlait de "the obstacle of the plugboard", et l'image du spaghetti dans le code en vient en partie. On voit une image de Vaneevar Bush et de son Differential Analyzer (1931, mais inventé entre autres par Lord Kelvin et cie en 1876) qui est gros comme ma salle à manger.

Walter Brown dit avoir commencé avec un IBM 650 utilisant des nombres bi-quinaires (inspiré des abaques). La mémoire « Core » est venue peu de temps après et était sur des tores dont les toroïdes représentaient un bit chacun. La manipulation demandait de la finesse et était surtout faite par des femmes. Ce type de mémoire a rapidement remplacé les tubes à vide. Les semiconducteurs ont remplacé les tores en 1975 mais il y en avait encore qui s'achetait en 1979. Un bloc de 128Ko était à peu près grand comme un adulte humain. Le mot « Core Dump » vient de cette époque.

Walter Brown parle ensuite du IBM 1620 qu'il dit avoir très bien connu. On parlait alors de composantes discrètes, éventuellement remplacées par des circuits intégrés. C'était gros comme un bureau de travail professionnel, avec un lecteur de ruban et un outil pour écrire sur un ruban. L'encodage des rubans était sur sept bits et est à la source des choix qui sont devenus le code ASCII. Il n'y avais pas de disque et il n'y avait pas d'imprimante. Le digit de 6 bits tenait lieu de ce qu'on appelle un byte aujourd'hui, avec 4 bits pour du Binary Coded Decimal, un bit de flag et un bit de parité (important à l'époque). Les câbles étaient énormes (gros comme un poignet) ce qui explique qu'on les plaçait sous le plancher (sinon, le risque de trébucher était trop grand). Les instructions étaient sur 12 bits et alignées à gauche sur une adresse paire. Il fallait payer plus cher pour un support matériel des indirections. Les instructions produisaient des ondes qui dérangeaient les ondes AM. Les mots mémoires étaient alignés à droite. Il n'y avait pas vraiment d'arithmétique à même la machine; on la réalisait avec des tables chargées au démarrage... Il y avait un brevet sur ces tables! Les nombres à virgule flottante (pré-IEEE754) sont venus plus tard.

Walter Brown dit qu'il y avait un levier d'arrêt d'urgence sur la machine, mais qu'on n'y touchait pas car il fallait ensuite faire un appel de service! Il y avait aussi une roulette permettant de choisir ce qu'on voulait voir (littéralement!) de la mémoire. On a une vidéo; ça faisait un vacarme!

Walter Brown : une première imprimante (Line Printer) nous est arrivée en 1959. C'était insonorisé car ça faisait beaucoup de bruit. Le code pour « Vertical Tab » était utile à cette époque et existe encore aujourd'hui. Le disque rigide (format machine à laver) est arrivé en 1962; c'était un IBM 1311. Capacité de 2 millions de digits (un million de caractères). On avait un compilateur FORTRAN II, chargé à partir de Punch Cards. La bibliothèque standard (en termes contemporains) était d'environ 2000 cartes. Ils avaient SPS (Symbolic Programming System), ce qu'on appelle du langage d'assemblage aujourd'hui. Le système d'exploitation était MONITOR I. On était encore loin du temps partagé...

Walter Brown nous présente une carte de FORTRAN avec le 'C' dans la colonne 1 pour les commentaires et quelques autres règles du genre. On a une petite présentation du langage. Les espaces n'étaient pas significatifs et étaient ignorés (brrrr...). Les variables étaient REAL par défaut. Il n'y avait pas d'opérateurs relationnels et il n'y avait pas d'opérateur logique; il y avait pas contre un « arithmetic IF statement »... Les noms étaient limités à six caractères significatifs et menaient à des jeux de mots (p. ex. : EVALU8). Il y avait un 6-bit ASCII (pas de minuscules) à l'époque. Tout était propriétaire à l'époque.

Walter Brown : anecdote. En FORTRAN II, on déclarait un tableau avec DIMENSION, mais les gens écrivaient souvent DIMENTION (faute de frappe), or ça compilait car... tout symbole assez long et débutant par un D était vu comme DIMENSION. Les étudiants écrivaient DUMBWAITER et un jour, quelqu'un d'extérieur à l'école s'en est aperçu...

Walter Brown présente un terminal de type « TeleType » (un ASR-33 pour Automatic Send-Receive, le premier appareil à utiliser ASCII). C'est là-dessus que BASIC a été conçu. Le symbole @choisi par Ray Tomlinson pour les adresses courriel vient du clavier de cet appareil.

Walter Brown termine avec une citation de J. V. Atanasoff. C'est émotif encore aujourd'hui.

Q : que pensez-vous de l'informatique contemporaine?

Walter Brown : nos outils sont un progrès considérable. J'ai encore quelques caisses de Punch Cards au sous-sol, incluant ma disseration doctorale. La programmation demeure la programmation, cela dit. Je sais que les programmeuses et les programmeurs de l'époque étaient souvent choqué(e)s que les programmes ne soient pas corrects du premier coup; l'idée du débogage a dû être inventée. On fait encore souvent les mêmes erreurs qu'à l'époque (des « off-by-one »)

Q : quel progrès fut le plus important dans les vingt dernières années?

Walter Brown : je pense que la plus importante est plus ancienne, soit l'architecture von Neumann. Avant ce moment, les machines avaient deux mémoires. L'influence de John von Neumann sur le monde contemporain est considérable; il pouvait évaluer des séries infinies dans sa tête, et a prédit le réchauffement climatique.

Patrice Roy – Slowing Down to be Faster - C++ and Divisible Algorithms in Real-Time Systems

J'ai fait mon possible. Je pense que ça s'est bien passé; j'ai eu quelques questions, et de l'interaction, en particulier de Timur Doumler, de Jason Turner et de Richard Powell.

Jason Turner – The Best Parts of C++

Jason Turner explique que c'est la quatrième fois qu'il donne cette présentation, chose rare pour lui. Il se présente brièvement, puis explique qu'il compte discuter d'approximativement 25 mécanismes du standard et de leurs auteurs. Il fait ensuite un petit sondage pour voir qui peut utiliser chaque version du langage et C++ 17 semble être la norme pour la majorité.

Jason Turner procède :

• Le standard lui-même est son numéro un. Ensuite...
• const
• RAII (durée de vie et finalisation déterministes)
• templates
• std::vector<T>, algorithmes et la « STL &»
• std::array<T,N>
• List initialization
• Les templates variadiques
• constexpr
• template variables
• auto
• auto return type deduction
• Objets appelables (foncteurs)
• λ (fermetures, techniquement)
• λ génériques
• range-based for loops
• Structured Bindings
• concepts
• string_view
• format(), print()... le formatage de texte
• ranges
• CTAD
• rvalues et références de relais
• Guaranteed Copy Elision
• =delete et =default
• unique_ptr<T> et make_unique<T>()
• Fold Expressions

C'est une belle liste. Jason Turner refait le tour par version du standard. J'aurais inséré variant, personnellement

Jason Turner parle de la grande qualité des outils que nous avons aujourd'hui (bon point!)

Lightning Talks

On y va. Temps limite ce soir : cinq minutes par présentation. Tony Van Eerd est le maître de cérémonie. Il injecte des mots de sagesse entre les présentations.

Dave Abrahams propose un petit quelque chose sur le modèle objet du langage Val, où tout est une valeur (sauf les entités mutables, qui doivent explicitement être accédées à travers des pointeurs). Passer par valeur n'oblige pas une copie, et si on peut éviter une copie, passer par valeur puis muter puis retourner ne fait pas mal. Sean Parent demande ce que ça donne; Dave Abrahams répond qu'on se débarasse des états mutables partagés. Il ne reste que les copies nécessaires. Vidéo : https://www.youtube.com/watch?v=KGL02mSaplE&feature=youtu.be

Jake S. Del Mastro dit __pourquoi la __BIBLIOTHEQUE_STANDARD__ est __illisible et pourquoi c'est nécessaire 🙂 Il a dû réimplémenter une partie de la bibliothèque standard pour un projet de code de niveau noyau. Il explique le rôle des préfixes __ et _Maj qui enlaidissent les symboles, et il explique l'impact de la compilation conditionnelle multiplateforme sur la lisibilité. Vidéo : https://www.youtube.com/watch?v=opq0W7StbeE&feature=youtu.be

Timur Doumler propose un Runner's Guide to C++ Conferences. Il parle de son expérience de course à pied depuis deux ans pour se remettre en forme. Il explique que c'était difficile pendant la Covid mais qu'il vivait dans un petit appartement alors ça lui a fait du bien! Il fait beaucoup de conférences pour le boulot alors pour s'entraîner en vue d'un marathonm il doit courir presque chaque jour. Vidéo : https://www.youtube.com/watch?v=cPqvFzPMYew&feature=youtu.be

Guy Davidson parle de C Shanty. Il vient du Royaume-Uni. Il dit souhaiter nous chanter une chanson dans son accent d'origine! Franchement, respect cher ami!

Jussi Pakkane parle de « Basics of anatomy in drawing for prospective artists ». Il y va une ligne à la fois, mais nous propose que le dessin ne fonctionne pas et nous dit pourquoi (je ne suis ps d'accord, car je peux le faire fonctionner, mais je vous ce qu'il veut dire). Il dit qu'on peut en quelque sorte prédire le futur à partir d'une ellipse et de trois lignes, et propose d'extrapoler pour des abstractions. Il parle de la difficulté d'exprimer en mots ce qu'on perçoit, intangiblement, comme brisés. Vidéo : https://www.youtube.com/watch?v=cHpz5YaqxAs&feature=youtu.be

Dean Moldovan parle de std::fs::patch en tant que correctif pour un bogue. Son équipe comprend neuf personnes, de huit pays au total, et... tous leurs noms débutent par un caractère ASCII. Jamais durant les tests n'ont-ils vu de bogue, jusqu'à ce qu'ils engagent... un canadien, qui a entré son nom, Loïc (avec un accent) et le nom des fichiers de configuration était corrompu! Il avaient un support de UTF-8 dans leurs autres outils, mais pas dans C++. Ils auraient dû utiliser std::filesystem::u8path() plutôt que std::filesystem::path() et tout se serait bien passé. Maintenant, ils savent! Refactoriser le code était complexe (le constructeur de string vers path est implicite!) et ils ne savaient pas comment écrire une règle de clang-tidy. Ils ont modifié les sources de la bibliothèque standard pour ajouter un [[deprecated]]! En ses mots : « c'est terrible, ne le faites pas... et ça a fonctionné à merveille! ». Vidéo : https://www.youtube.com/watch?v=-7ebQqzGRKE&feature=youtu.be

Rémi Drolet présente des aspects de variant vers une FSM qui enrichissent sa bibliothèque. Il montre comment on peut utiliser un variant pour faire une action / transition sur la base de ce que le variant contient et d'une nouvelle valeur. Ça repose sur un if constexpr qui fera en sorte de ne pas évaluer les appels impossibles. Vidéo : https://www.youtube.com/watch?v=i8qc-c8DltY&feature=youtu.be

Gaelan McMillan parle de « Drum Machines... as automata ». Il aime les automates! Son automate reconnaît des sons de percussion (et fait les sons pour nous l'expliquer!)

Adrian C. Popescu parle d'une expérience d'analyse statique avec clang. Il explique ce que sa compagnie (de développement de jeu) fait avec l'analyse statique (suivi des allocations, sécurité, stabilité, modélisation du code existant, etc.). Il a utilisé clang-analyze. La trace produite est vraiment intéressante. cppcheck est chouette aussi. Ça n'attrape pas tout, cela dit. Vidéo : https://www.youtube.com/watch?v=3iNFNowpBUo

Francis Lemaire parle du coût au quotidien de ne pas utiliser les algorithmes standards, chiffres à l'appui. Il pense que pour les fins du développement, la plupart des gens utilisent un mode Debug ou -O0. Il dit que dans certains cas, la différence est de deux ordres de magnitude entre une implémentation maison naïve et ce que propose le standard, et montre le code de son mismatch « maison ». Tony Van Eerd fait remarquer que si on compile naïvement avec MSVC, tous les accès par un itérateur testent les bornes et ça tue complètement l'efficacité du programme. Vidéo : https://www.youtube.com/watch?v=tL9uBjLtYPI

(Tony Van Eerd cite Bean Deane!)

Tristan Brindle parle de « Fun. Declarations ». Il montre du code qu'on peut mal comprendre sans contexte (la même écriture peut vouloir dire plusieurs trucs différents). Quelle horreur... Il fait un plaidoyer pour que la syntaxe puisse être consommée par des humains...

Max explique pourquoi « Nix > Docker » selon lui. Sa diapo est datée... 31 décembre 1979... Il explique les difficultés associées à Docker et comment Nix permet de mieux faire. Vidéo : https://www.youtube.com/watch?v=mNmaWeVoZE8

Amir Kirsh propose « Filling the Bucket ». Il dit enseigner C++ et favoriser les questions sur la lecture du code plutôt que sur l'écriture du code. Il montre une fonction de 20 lignes (récursive avec cinq return, rien de moins) et dit qu'il posera des questions¸sur le code (il y a du comportement indéfini dans son code, je lui en glisse un mot). Vidéo : https://www.youtube.com/watch?v=_WXxPFel2gU&feature=youtu.be

Pier-Antoine Giguère y va d'un enthousiaste « Programming is fun! ». Il relate une expérience avec un tutoriel de tracé de rayons et la visualisation en temps réel qu'il y a ajouté. Franchement adorable! Vidéo : https://www.youtube.com/watch?v=opq0W7StbeE&feature=youtu.be

Tara Walker – Yes! Robotics is for the for C++ Developer

Tara Walker se présente et explique de quoi elle parlera (un truc nommé ROS, et intégrer le code C++ en robotique). Elle présente ROS plus comme un intergiciel pair-à-pair pour des robots, produit à code ouvert développé à Stanford. Il existe plus d'une distribution de ROS. La philosophie est d'avoir un système réparti avec communication pair-à-pair en plusieurs langages. Les concepts de ROS1 et de ROS2 ne sont pas tout à fait les mêmes : ROS1 préfère les nodes et les nodelets, ROS2 préfère les components.

Tara Walker présente le modèle de communication de ROS1, puis explique (sans surprises) que la configuration de l'environnement de développement est un peu déplaisant (c'est pas la partie de je préfère non plus, règle générale). Elle va dans le détail et je ne prends pas de notes.

Tara Walker demande s'il y a des trucs intéressants en robotique aujourd'hui. On entend quelques trucs amusants (Amazon Warehousing, Self-Crashing Cars), des trucs plus sérieux (faire des opérations sous terre là où l'oxygène se fait rare). Elle explique l'organisation des projets et explique le fonctionnement de catkin, leur Build System basé sur CMake. L'outil roslaunch lance plusieurs noeuds, ce qui peut démarrer un roscore. Les fichiers .launch contiennent du XML.

Dave Abrahams demande de quoi les programmes ROS ont l'air; Tara Walker dit que c'est du code C++. L'intérêt de ROS est de standardiser l'expérience de programmation, qui était fragmentée auparavant. La bibliothèque cliente est roscpp. Les services de base sont l'identité des noeuds, des fonctions de messagerie (incluant des systèmes événementiels) et de Logging, en plus de services de réaction au passage du temps.

Tara Walker présente un « Hello World » de robotique. Elle présente les types de Node Handles possibles dans ce modèle, puis décrit le modèle de programmation qui y est mis de l'avant.

Stephanie Brennan : quels sortes de paramètres fais-tu circuler?

Tara Walker parle de drones. On ne contrôle pas la météo. Que fait-on quand le vent s'anime? Ça influence le positionnement du drone. Avec intelligence artificielle, on doit adapter les paramètres de navigation. Elle parle aussi de travaux souterrains quand il a plu pendant plusieurs jours. Tara Walker dit que les humains ont une rétroaction tactile alors que les robots, a priori, n'en ont pas; elle parle de l'haptique qui est dispendieuse mais permet de compenser.

Tara Walker mentionne ensuite son simulateur, Gazebo, qui inclut des environnements simulés, des robots simulés, des capteurs, etc. avec une interface ROS. Il y a aussi rviz pour visualiser un robot dans un environnement.

Adrian C. Popescu : qu'utilises-tu à titre d'outils, machine virtuelle et autres?

Tara Walker j'utilise ROS pour Windows. On peut utiliser Gazebo, rviz, etc. et le code est ouvert. À titre d'IDE j'utilise Visual Studio Code.

Tara Walker fait une petite démo, mais ça ne va pas comme elle veut (ça arrive). On lui demande à quel point il faut connaître le matériel pour faire de la robotique et elle dit plus ou moins (ça ne peut pas nuire, évidemment). Ensuite, elle montre qu'elle a un système à plusieurs terminaux et charge des distributions différentes dans chacun. Enfin, elle dit qu'il y a désormais un microROS pour l'IdO. Ça permet de programmer des jouets pour enfants entre autres choses. Elle mentionne Zephyr, Azure RTOS, NuttX et FreeRTOS.

Q : les Build Systems sont-ils imposés ou au choix?

Tara Walker : ça dépend comment tu travailles. Avec certains robots, on est pris avec des Build Systems spécifiques.

Q : que recommanderais-tu à des débutants?

Tara Walker propose quelques trucs, mais dit que ros.org a de la bonne documentation.

Adrian C. Popescu : je fais des jeux vidéo. Avez-vous pensé utiliser Unreal pour fins de simulation plutôt que Gazebo?

Tara Walker : ils ont effectivement des outils de simulation robotique chez Unreal maintenant, et c'est bien. Il y en a un avec Unity aussi. Ça fonctionne avec Rust aussi

Richard Powell : si on mettait le code du Build System sur le robot, il pourrait se reconstruire lui-même n'est-ce pas?

Tara Walker : on peut probablement, mais à cause des contraintres TR on se demande si c'est la chose à faire. On tend à préférer une IA adaptative à un programme qu'on doit recompiler.

Q : si un paquetage ROS1 existe mais n'existe pas en ROS2, que faire?

Tara Walker : il y a un ROS Bridge qui fait un travail raisonnable

Q : y a-t-il un effort de convergence entre ROS1 et ROS2?

Tara Walker : c'est un monde réparti aujourd'hui et ROS1 n'était pas bien adapté à cette réalité. Ils veulent que les gens migrent à ROS2. La documentation de ROS1 est meilleure par contre alors ça reste chouette pour débuter.

Bryce Adelstein Llebach – Multidimensional C++

Bryce Adelstein Llebach présente std::mdspan qui est l'analogue multidimensionnel de std::span (C++ 20) pour C++ 23. On parle d'une abstraction « non-owning » donc légère à copier. Les métadonnées peuvent être dynamiques ou statiques. Ce que std::mdspan assure est la correspondance (le Layout) entre le substrat et les indices. On peut d'ailleurs faire des accesseurs maison qui testent les bornes si tel est notre souhait. Il présent ensuite std::extents et std::dynamic_extents, et il se trouve que ça interagit bien avec CTAD sinon la syntaxe serait un peu lourde. Un alias std::dextents est utilisé pour les cas où tous les « extents » sont dyamiques, mais on peut combiner std::extents et std::dynamic_extents dans un même std::mdspan

Bryce Adelstein Llebach montre que std::mdspan est paramétré sur T, Extents, LayoutPolicy (std::layout_right par défaut, ce qui signifie « Row Major » ce qui est le défaut en C++ et en NumPy; l'alternative est std::layout_left qui est le modèle de Fortran et MATLAB; on peut aussi faire nos propres Layouts, et ceux-ci peuvent être non-contigus et peuvent être tels que plusieurs indices arrivent au même élément) et AccessorPolicy (std::default_accessor<T> par défaut). Ça profite du support de multiples paramètres dans operator[]. Il y a plusieurs variantes intéressantes de constructeur à explorer ici.

Bryce Adelstein Llebach montre comment il est possible d'utiliser les Layouts paramétriques pour utiliser std::mdspan avec des Eigen::Matrix, des matrices du BLAS, de Blaze, etc. Le truc le plus simple pour que nos propres types de matrices collaborent bien avec std::mdspan est de leur ajouter un opérateur de conversion implicite. Il montre aussi submdspan() qui permet de décrire comment obtenir une tranche du substrat et de faciliter la logique d'accès aux éléments.

Il a de bons exemples d'algos parallèles et de bonnes pratiques. À retenir pour fins d'expérimentation.

Bryce Adelstein Llebach met de l'avant que les algorithmes standard d'aujourd'hui sont axés sur les séquences unidimensionnelles, et qu'on travaille à standardiser les pratiques existantes en algèbre liénaire. Il montre std::scaled(), qui est un algorithme paresseux, de même que std::transposed() qui fait ce que son nom annonce.

Bryce Adelstein Llebach indique que mdspan de supporte ni ranges, ni itérateurs. La raison est... la vitesse. Ça risque de coûter trop cher dans la gestion des indices pour une structure multidimensionnelle et ça tend à mal se vectoriser. C'est un obstacle à l'adoption, cela dit : les itérateurs et les ranges facilitent la paramétrisation et la composabilité. Si on veut du code générique, agnostique quand au subtrat, au rang, au layout... mais pour un mdspan l'ordre de parcours est moins clair. L'enjeu est l'ordre de parcours par défaut. Il dit qu'on peut envisager un parcours index-wise et un parcours element-wise et donne des exemples d'algorithmes dans les deux cas. Il examine le code généré selon certaines approches... Dans les cas qui reposent sur les ranges, on tend à avoir du code non-vectorisé (mais on peut comprendre la difficulté pour un compilateur). C'est une étude de cas intéressante.

Bryce Adelstein Llebach en arrive à proposer de simplement (!) offrir des mécanismes différents pour parcourir des mdarray que ceux prévus pour des intervalles à demi-ouverts. Il propose un mdbegin et un mdend accompagnés d'un mdrank qui seraient compris par un range-based for pour générer du meilleur code (à l'interne, générant des boucles imbriquées à partir de mdbegin<N-1> jusqu'à une débutant à mdbegin<0> où N serait inféré de mdrank<Space>)

Bryce Adelstein Llebach montre ensuite le code vers lequel nous mènerait cette direction. C'est joli, même si par nature le calcul matriciel est non-trivial.

Q : j'ai vu des Structured Bindings pour décomposer des paramètres. Le comité veut-il aller là?

Bryce Adelstein Llebach : je veux les convaincre! Chaque fois qu'on manipule des std::tuple, ne pas avoir ça amène du bruit inutile

Richard Powell : peut-on comparer deux mdspan ensemble?

Bryce Adelstein Llebach : quel résultat souhaites-tu avoir?

Richard Powell : une comparaison en profondeur

Daisy Hollman : ça donne une comparaison de surface car c'est un type référence

Bryce Adelstein Llebach : t'es mieux avec std::equal()

Richard Powell : peux-tu faire des Reverse Slices?

Bryce Adelstein Llebach : non

Daisy Hollman : on en a parlé

Tony Van Eerd : std::span<T> a-t-il un support des comparaisons?

Bryce Adelstein Llebach : pas sûr, mais je pense que std::equal() a plus de sens

Olivier Giroux – Forward Progress in C++

Il y a un sous-titre sur la diapositive-titre, soit « And other languages that don't define it themselves », ce qui rend le tout encore plus intéressant 🙂

Olivier Giroux commence en félicitant les organisateurs. Il fait des blagues sur le Keynote d'hier et le concept de progrès. Il explique qu'une garantie de progrès est plus subtile que « ton programme ne figera pas ». Il y a plusieurs subtilités (entre autres, il y a des conditions de validité et il y a trois garanties de progrès distinctes).

Olivier Giroux indique que ton intérêt envers la question a démarré à la rencontre de programmes qui figeaient, par exemple sur CUDA avec des verrous. Le matériel devrait selon lui supporter les modèles de programmation, et quand ça ne survient pas, le matériel est en faute. Il propose une notation pour indiquer les programmes brisés ou ceux qui fonctionnent mais ... beurk. Si on n'inclut pas <thread>, <future> ou <execution> on a un programme monothread.

Olivier Giroux rappelle qu'un programme qui n'a pas de conditions de course ou de comportement indéfini n'a pas de problèmes de Forward Progress. Il a un très bon programme montrant que l'accroissement de la « performance » des programmes dépend du nombre croissant de coeurs.

Olivier Giroux enchaîne avec des exemples brisés. Note : un thread détaché qui survit à main() est dangereux, particulièrement si des DLL sont impliquées.

Olivier Giroux définit la concurrence comme le fait que des tâches concurrentes peuvent observer les effets l'une de l'autre. Il en arrive à un exemple où il y a de la véritable concurrence et produit une démarche en trois temps : quels sont les fils d'exécution? Quelles sont les étapes clés dans l'exécution pour les garanties de Forward Progress dans la machine abstraite (termination, I/O, operations sur atomiques ou volatiles, opérations de synchronisation – synchronizes-with ou blocks-until)? Quand les étapes seront-elles faites?

Olivier Giroux dit qu'il y a un « should » dans le texte (au sens du standard, c'est un « encouragement normatif » 🙂) donc tout programme qui bloque pourrait figer. Le « should » est au cas où les usagers joueraient avec les priorités...

Concurrent forward-progress: threads should take a step. Then they should eventually take another step. (avec C++ 11 et C++ 14, c'est la seule)

Olivier Giroux aborde la question des deadlocks. Dans son graphe, il y a une dépendance circulaire où les acquire et release se croisent. Les garanties de progrès sont maintenues, mais on les utilise mal et on crée en quelque sort une boucle infinie (on peut, sous la couverture, prendre un nombre infini de pas)

Olivier Giroux : parallel tasks are forbidden from observing each other's effects. Si on prend un modèle parallèle mais on pose des gestes de programmation concurrente, que se passera-t-il? On a du Discovered Concurrency (sorte de parallélisme pragmatique). Il utilise un std::barrier pour les besoins de la démonstration. Il fait une présentation schématique des gains ou des pertes de vitesse en fonction du nombre de threads et du nombre de coeurs et de la taille des tâches

Olivier Giroux examine l'enjeu de subdiviser le travail pour amortir les coûts, ce qui l'amène à examiner le Parallel Forward Progress. C'est particulièrement utile quand les tâches sont petites. Pour comprendre le Parallel Progress, il passe par une sorte de thread pool. Il discute de Tail Effects qui surviennent quand le même nombre de tâches est consommé par chaque thread, mais les tâches ne prennent pas le même temps. Ensuite, il parle d'Oversubscription, puis de famine (il construit un cas qui paralysera).

Olivier Giroux présente ensuite le « Boost Blocking » (qui porte un autre nom en C++) et montre comment un peut réintroduire du progrès quand le système est en famine. C'est clairement exprimé.

Parallel Progress: threads don't eventually take a step. If blocked on forward-progress delegation, then take at least a step. Then takes another step. (valider le libellé avec les diapos)

Olivier Giroux présente un autre exemple avec un livelock.

Dave Abrahams : en quoi est-ce que nous devrions être préoccupés par la différence entre un deadlock et un livelock?

Olivier Giroux : ça aide à la rigueur de la pensée. Un deadlock est une condition insatisfiable qui ne brime pas le progrès. Un livelock est une autre bestiole. Les deux figent le programme

Weak Parallel Progress : threads don't eventually take a step. If blocked on forward-progress delegation, then at least one takes a step. Then at least one takes another step.

Olivier Giroux montre comment atteindre chacune des garanties en C++ (bonne idée)

Olivier Giroux mentionne que sous std::par_unseq on ne peut même pas utiliser de std::atomic<T> (son exemple fait une écriture sur un tel objet), car par_unseq est weakly parallel et unsequenced.

Olivier Giroux présente son comportement indéfini préféré 🙂 C++ peut être implémenté avec un ordonnanceur non-préemptif si ce dernier sont où sont les étapes du code parallèle ou concurrent

Olivier Giroux note que le progrès épargne... et provoque des conditions de course. Il not aussi que l'atomicité éventuelle implique un progrès éventuel. Il note que « Roach Motels should not be a problem » (they check in, they don't check out). Ceci est en lien avec les garanties associées aux opérations acquire et release (on peut prendre une opération hors de la section critique et l'amener en dedans, mais pas l'inverse)... il montre que le texte n'est pas clair qu'on ne peut pas monter un acquire avant un release (les implémenteurs ne le font pas, heureusement!)

Olivier Giroux parle de Lock-Freedom. C'est pas aussi simple que de ne pas utiliser de mutex; faut aussi des atomic<T>::is_lock_free() et il faut abandonner l'idée de progrès. Il y a un petit problème de nomenclature dans le standard où on parle de obstruction-free, ce qui requiert une capacité de back-off, et le standard ne dit pas comment faire ça.

Olivier Giroux parle des statiques magiques et de par_unseq... Le standard ne dit pas que c'est interdit, mais le code équivalent avec call_once() est interdit. Il montre d'autres cas avec par_unseq qui font peur...

Daisy Hollman : à propos de deadlocks et livelocks, mon impression est qu'un livelock a plus de probabilités de fonctionner par accident

Olivier Giroux : oui, c'est le cas

Sean Parent – "The Tragedy of C++, Acts One & Two"

Sean Parent dit ... je ne le sais pas car j'ai dû aller prendre mon train vers la maison, mais j'ai très hâte de voir le tout quand ce sera en ligne sous peu!