À propos de cppcon 2019

Quelques raccourcis :

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.

Grâce à l'Université de Sherbrooke (en particulier, grâce à Jean Goulet et à Claude Cardinal du CeFTI) et au Collège Lionel-Groulx (en particulier à Éric St-Jean, à Lucia Lepage et à mes collègues du département d'informatique), j'ai le privilège de participer à CppCon 2019.

Ce qui suit est une sorte de journal de voyage, avec éléments humains et éléments techniques. Au besoin, référez-vous à ce glossaire : ../../Lexique/lexique-wg21.html

Notez que j'ai eu une semaine très, très occupée, et que j'ai assurément oublié de mentionner plusieurs rencontres. Si je ne vous ai pas mentionné, ça en dit plus sur ma mémoire défaillante que sur l'intérêt que je vous ai porté.

Pour un peu de bagage supplémentaire sur l'événement, voir :

Pour les journaux de voyage d'autres participants, voir :

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

Jour -3 13 septembre

Je suis parti de la maison vers 5 h du matin pour mon vol de 8 h. Grâce à mes illustres collègues Marc Beaulne et Philippe Simard, j'ai pu alimenter mes étudiant(e)s de 3e session avec des activités intéressantes à faire en mon absence (j'ai mis le matériel à leur disposition en attendant mon avion), et grâce à mes tout aussi illustres collègues Maxime Barakatt (qui me remplacera) et Pierre Prud'homme, mes étudiant(e)s de 1re session seront entre bonnes mains pendant mon absence la semaine prochaine. Avec mon épouse Za qui a organisé mes bagages avec un talent pour l'organisation que je n'ai absolument pas (merci mon amour!), me voilà bien entouré.

Mon trajet pour aujourd'hui se fait en deux temps, soit de Montréal à Las Vegas, avec un transit de deux heures environ, puis de Las Vegas à Denver, où j'irai prendre ma chambre et finaliser ma préparation pour la classe de maître que je donnerai en fin de semaine (voir https://cppcon.org/class-2019-thinking-small/ pour des détails), avant d'entrer dans le feu roulant du colloque en tant que tel.

Ce sera une très grosse semaine pour moi : en plus de cette classe que je donne sur deux jours, nous avons les cinq jours de colloque, dans lesquels je donnerai deux conférences soit une sur l'enseignement de C++ à des débutants (https://sched.co/Sfmv) et une autre portant sur certains mythes à propos desquels il y a peut-être lieu de se questionner (https://sched.co/Sfst); j'ai eu le plaisir d'offrir cette dernière au C++ Users Group de Montréal cet été (merci aux organisateurs, en particulier à Gabriel Aubut-Lussier!). Mercredi, toute la journée, nous tiendrons une rencontre de SG14, le groupe d'étude sur les systèmes à basse latence de WG21. Enfin, à la fin de la semaine (vendredi après-midi), je dois revenir vers la maison pour ma propre collation des grades (enfin!) qui se tiendra samedi le 21 septembre. Ce sera... physique!

En rafale, les faits saillants de la première partie du trajet :

J'ai eu le plaisir de voir et d'entendre mon amoureuse Za et mon garçon Ludo alors que la paire se préparait pour l'école. Malheureusement, depuis la plus récente mise à jour de pilotes sur mon ordinateur portatif, Skype et mon microphone ne veulent plus collaborer (je peux utiliser mon microphone avec d'autres outils, seul Skype semble poser problème) alors j'ai dû mimer mes messages et répondre aux profondes questions d'arithmétique de mon plus jeune

Comme indiqué plus haut, j'ai pu préparer un peu les activités en vue de mon absence cette semaine en attendant l'avion à Montréal (j'ai poursuivi les travaux pendant l'escale à Las Vegas)

Incident légèrement amusant en embarquant dans l'avion : un couple de personnes dans la quarantaine juste devant moi a essayé (par accident) d'entrer avec les mauvais passeports. La situation s'est réglée avec humour, mais la dame qui a accueilli les passeports permutés de l'homme et de la femme a mis quelques moments à comprendre ce qui se passait

J'étais tout juste à côté de la sortie de secours dans l'avion (en fait, j'étais le voisin de la dame qui occupait le siège de la personne responsable d'ouvrir la porte s'il y a un problème). L'air de rien, ça nous donnait un petit bonus en termes d'espace disponible. Ma voisine était sympathique : une dame dans la trentaine qui allait rejoindre son amoureux dans un voyage de golf, une passion que les deux partagent. On a bavardé un peu, mais elle a passé l'essentiel du trajet à regarder des émissions de télévision entreposées sur son téléphone alors que, pour ma part, j'écoutais les plus récents balados de La soirée et encore jeune (hi-la-rant!) et l'émission tournée en Abitibi dernièrement de la balado de Fred Savard.

Une voisine en biais regardait quant à elle la saison 2 de Thirteen Reasons Why. Je viens de finir la saison 3 avec mon amoureuse Za dernièrement; c'est très bien comme série, ce truc. En attrapant des images de la saison 2 de temps en temps, j'ai par contre remarqué que quelques personnages des deux premières saison étaient totalement absents de la troisième. Étrangement, en regardant la troisième, je ne m'en étais pas aperçu.

Truc moche pour un trajet aussi long : aucune prise de courant dans l'avion. Pas même de prise USB. J'ai quand même travaillé sur mes présentations, mais en ménageant la pile de mon ordinateur portatif.

Arrivé à Las Vegas, un constat s'impose : il y a une image de marque ici. L'aéroport est littéralement plein de machines à sous! J'en ai croisé quelques centaines en marchant du point où je suis arrivé vers celui d'où je partirai. Celles et ceux qui me connaissant savent que c'est vraiment, mais vraiment pas mon genre de truc. En plus, ça fonctionne : les gens y jouent. Eh ben. En retour, l'aéroport est propre est les gens sont gentils.

En quittant Las Vegas, j'étais assis au bord de la fenêtre, ce qui m'a permis de jeter un coup d'oeil à cet étrange panorama : un bâtiment avec une énorme affiche annonçant David Copperfield, une grosse pyramide, à côté d'un gros sphinx, à côté... d'un resto d'une chaîne de restauration rapide avec deux arches jaunes. Vu du ciel, on constate que pratiquement chaque maison (jusqu'à l'horizon) est accompagnée d'une piscine creusée.

Le trajet de Las Vegas à Denver fut relativement bref. En gros, cela implique de survoler le désert du Nevada. À un moment donné, on pouvait voir un gigantesque damier de végétation et de désertification (de gros carrés arrangés comme sur un plateau d'échecs); il doit y avoir une raison pour ça, mais je ne la connais pas.

À Denver, l'aéroport est très gros (quatre terminaux, reliés pas train), mais bien organisé. Je suis venu par ici en 2014 pour un colloque en lien avec ma thèse de doctorat. Cette fois par contre, nous logeons au Gaylord Rockies, un hôtel véritablement immense; on le voit de l'aéroport, et on le voit gros, même s'il est à 30-35 USD de taxi de distance. Pour voir des photos, zyeutez https://www.marriott.com/hotels/travel/dengr-gaylord-rockies-resort-and-convention-center/. Du fait que je donne un cours et deux conférences, je n'ai pas à payer ma chambre (heureusement; c'est pas donné!).

J'ai parlé un peu avec ma belle Za et mes deux plus jeunes, Vayda et Ludo. J'ai reçu une note de Jon Kalb avertissant les gens qui enseigneront demain (dont moi) qu'il souhaite nous rencontrer vers 19 h 30 heure locale (je vais aller faire un tour; suffit de trouver l'endroit... Il faut une carte pour naviguer dans l'hôtel!). Je vais essayer de faire un peu de repèrage avant de me coucher pour savoir où aller demain matin.

En allant vers le lieu de rencontre désigné par Jon Kalb, j'ai croisé Gabriel Aubut-Lussier qui a marché un peu avec moi. Il avait exploré les lieux, étant arrivé un peu plus tôt, et m'a décrit les facilités (c'est un peu décadent... et on n'en profitera même pas parce qu'on va travailler tout le temps). J'ai trouvé Jon Kalb, visité ma salle de classe (qui semble bien correcte), trouvé le nom et le mot de passe du Wi-Fi pour demain, etc. Jon Kalb avait besoin d'aide pour aller chercher la nourriture pour son goûter (Brett Searles, toujours extrêmement serviable, était allé chercher de l'indien) alors je suis allé donné un coup de pouce, avec Arthur O'Dwyer (qui passait par là) et Kevin Carpenter.

La bouffe était très bonne, et il y en avait beaucoup contrairement à ce que Jon Kalb avait annoncé : ils ont tenu une petite réception à la pizza hier soir ici pour les bénévoles locaux, mais peu sont venus alors il restait de la pizza froide et du barbecue à faire réchauffer, en plus du poulet au beurre, du riz, du garam marsala, etc. C'était bien bon. Il se trouve que, occupant une partie importante de l'espace de conférence (en soi immense, mais nous serons quand même plus de 1000 personnes pour l'événement), l'hôtel nous a laissé l'accès à la « suite présidentielle », une espèce d'appartement immense qui ressemble plus à un condo, ce qui permettait de recevoir les gens ce soir (il y avait une vingtaine de personnes quand je suis parti). L'ambiance était chouette, j'ai pu bavarder un peu avec Matt Godbolt (toujours sympathique) et avec Bryce Adelstein Lelbach (qui a pris un de mes anciens étudiants, le brillant Francis Lemaire, à titre de stagiaire chez Nvidia cet automne). Je ne suis toutefois pas resté bien longtemps car j'ai encore beaucoup à faire, et une grosse semaine m'attend... J'ai besoin de mon temps!

Petit bonjour à ma belle Za, et travail pour les préparatifs de la fin de semaine, avant un dodo franchement mérité.

Jour -2 14 septembre

Je donne aujourd'hui et demain un cours nommé Thinking Small, destiné à des gens intéressés par le contrôle sur la taille des programmes et des objets qu'ils contiennent. Mon cours se donnera dans la salle Summit 5 (j'étais fatigué en arrivant ici, et j'ai eu besoin d'aide pour la trouver).

Douche et rasage au lever (ma lame de rasoir approche de la fin de sa vie utile; heureusement, j'ai apporté des backups!). J'ai défait ma valise pour constater ce que ma belle Za y a placé pour moi (elle a préparé ma valise, l'a organisée avec une précision d'orfèvre – c'est impressionnant, et c'est apprécié!). De l'excellent travail, des trucs qui font sourire, et ... un chandail blanc, perdu dans l'océan de chandails noirs que je porte normalement. Elle devait bien rire en préparant tout ça 😊

J'ai ensuite trouvé comment faire fonctionner la petite machine à café de la chambre, et je me suis remis à la préparation de ma journée.

En rafale :

Après le cours, j'ai parlé longtemps avec John Plaice et Gabriel Aubut-Lussier, qui est arrivé hier comme moi mais profite des lieux (il est allé se baigner, faire du vélo, etc.). Gabriel m'a proposé de louer un vélo pour aller trouver un resto (il n'y a rien à moins de 50 minutes de marche de l'hôtel), mais si vous me connaissez, vous savez que l'équilibre requis pour faire du vélo n'est pas quelque chose que je possède, et je n'ai malheureusement pas de budget pour me promener en taxi (j'ai pris un petit bol de salade et une petite bière au marché de l'hôtel en soirée : 16 USD). J'ai aussi bavardé avec quelques autres amis (Jens Weller, Miro Knejp, Fred Tingaud, Bob Steagall, Lisa Lippincott, etc.) croisés ici et là.

En soirée, j'ai parlé un peu avec ma belle Za, ma grande fille Marguerite et mon garçon Ludo, et j'ai travaillé sur mon matériel pour demain et pour mardi matin.

Jour -1 15 septembre

Belle surprise ce matin : Jon Kalb nous a informé par courriel que Nicolai Josuttis a produit une édition spéciale de son nouveau livre sur C++ 17 et que ce livre est offert gratuitement en téléchargement pour tous les gens qui participent au colloque. Wow! Je me suis prévalu de cette offre (Nicolai est un excellent auteur).

J'ai travaillé sur des exemples supplémentaires pour aujourd'hui, hier soir et ce matin. Mieux vaut en avoir trop que ne pas en avoir assez. Une vingtaine de pages d'exemples supplémentaires en annexe d'un bloc de diapos, un thème de plus, deux déclinaisons inhabituelles d'une voie de contournement pour un problème dont nous allons discuter... J'aurais voulu faire plus, mais c'est un départ.

J'ai parlé à ma belle Za et à mon grand Ludo, mais brièvement car j'ai beaucoup à faire. J'ai aussi eu des nouvelles tristes de mes amis les Paventi, à qui j'envoie des câlins en cette période difficile.

Je suis parti vers ma salle de classe vers 8 h 5. J'ai quelques participants qui n'étaient pas familiers avec quelques a priori du cours (ce qui implique de la multiprogrammation, chose qu'on rencontre moins dans certains domains d'application comme celui des systèmes embarqués). J'ai bavardé succinctement avec le sympathique Jan Wilmans dans l'ascenseur. Les gens commencent à arriver en masse.

Staffan Tjernström est arrivé avant moi dans la salle de classe; il prépare son Lightning Talk pour cette semaine. Très chic type. En allant me chercher un café, j'ai croisé Billy Baker (qui a un très beau chapeau haut-de-forme de Mickey Mouse) et John Plaice, qui semble d'excellente humeur.

La journée s'est bien déroulée. Très technique, très rempli, questions de la salle, discussions animées. J'ai terminé à quelques minutes de la fin de la journée, et je suis resté près d'une demi-heure après la formation pour répondre à des questions. Ce fut fatigant, mais très agréable. En plus, belle surprise : Jon Kalb a réussi à donner un tee-shirt de l'événement à toutes celles et à tous ceux qui ont suivi un cours, ce qui a semblé les ravir.

Le goûter du matin était sucré (petits muffins, fruits); le repas du midi était bon (beaucoup de légumes, de petits sandwiches très goûteux), même si je n'ai pas vu le dessert (sais pas où il était); en après-midi, c'était des crudités et du hummus, ce qui faisait tout à fait mon bonheur (la friture d'hier était goûteuse, mais je suis plus un amateur de légumes).

Mon ami Billy Baker doit me trouver un peu plate; je suis allé le saluer après le cours, et comme il me demandait si je voulais aller manger une bouchée, j'ai dû lui dire que je devais aller reposer ma voix, qui est usée après deux jours pleins de prestation. Je suis d'ailleurs arrivé à ma chambre et je me suis étendu... J'ai perdu quelques minutes par épuisement.

J'ai parlé un peu à ma belle Za, échangé de manière épistolaire avec un ami (Jarryd Desmeules) qui découvre les joies de l'enseignement, puis je me suis dirigé vers la cérémonie d'accueil qui débute à 20 h, heure locale.

Une belle cérémonie. J'ai croisé Isabella Muerte dans l'ascenseur et nous avons bavardé le long du chemin. La communauté de C++ est une belle communauté dans l'ensemble, et les gens étaient heureux de se voir / de se revoir. J'ai bavardé avec beaucoup, beaucoup de gens, en particulier Andrew Sutton qui vient de quitter l'enseignement pour se lancer en affaires, et Billy Baker qui a vécu toute une frousse sur une route de montagne après notre dernière rencontre mais est toujours bien en vie (ouf!). J'ai aussi bavardé avec plusieurs gens dont c'est la première présence à CppCon, revu des tas de membres du comité et d'autres gens que je croise souvent à CppCon (Nicolas Fleury, en particulier, mais faut dire qu'on reconnaît vite notre accent dans une foule 😊). J'ai aussi échangé sur la cuisine faite maison avec Yuval Hager, qui fait de la pizza avec du levain. J'ai par contre manqué plusieurs personnes, dont Jonathan Boccara avec qui j'échange semi-régulièrement par écrit, mais que je n'ai pas encore rencontré en personne, et mon vieil ami Steven Pigeon; les deux sont arrivés après mon départ de la réception, si je me fie sur leurs tweets de soirée. Pas grave, on se verra sûrement plusieurs fois cette semaine.

La compétition d'affiches qui se tenait dans la salle de réception était intéressante, mais je n'ose pas voter car j'étais sur le comité qui les a sélectionnées. Quelques-unes en particulier donnaient dans le High Performance Computing, un sujet important dans le monde de C++. Ce sera chouette de voir comment les gens vont voter. Ce dont je suis content, c'est qu'il y avait plusieurs individus pour chaque affiche, et que les présentateurs interagissaient avec leur public. On ne veut pas que quelqu'un soit isolé dans de tels moments. Des fois, ces affiches donnent des idées (j'ai implémenté quelques trucs que j'avais trouvé intéressants sur les affiches quand j'ai visité OOPSLA en 2007).

De retour à ma chambre, j'ai regardé ce qu'on nous avait donné : j'ai deux chandails de CppCon (un à titre d'instructeur, un à titre de participant), et un sac qui contient quelques trucs sympa (en particulier, une gourde à l'effigie de l'événement). Ensuite, j'ai un peu échangé avec mon amoureuse Za et je me suis endormi. Je vais espérer retrouver ma voix d'ici ma présentation de mardi matin.

Jour 0 16 septembre

Le décalage horaire est toujours un peu violent sur moi. Je me suis réveillé (sans être dans un état tout à fait fonctionnel) vers 4 h 30 ce matin comme les deux précédents, mais c'est Ok car j'ai vraiment beaucoup à faire.

Outre les trucs de base (douche, se faire un café), j'ai préparé ma journée (certains choix restaient à faire; il y a tellement d'options ici!) et je me suis remis à la préparation de ma présentation de mardi matin qui avance à pas de tortue. Je vais aussi vouloir corriger quelques trucs incorrects sur mes diapos de la fin de semaine (les étudiant(e)s ont eu la gentilesse de m'écrire ce qui clochait pour que je m'en souvienne, et pour que je n'aie pas à arrêter le cours) pour que les participant(e)s partent avec du matériel de classe qui soit correct.

Tenir un journal de bord comme celui-ci demande un peu de travail chaque matin (placer les liens pour être efficace, préparer le formatage de base) car quand la journée commence vraiment, c'est un feu roulant ininterrompu. Il me faut une bonne demi-heure pour avoir un squelette de journée suffisant pour fonctionner.

Je fais aussi un peu de logistique avec mes étudiant(e)s à distance. Le collège me remplace avec les étudiant(e)s de première année, mais pas avec les autres, ce qui est correct (j'ai alimenté les autres de traval) mais entraîne un peu de confusion. J'essaie aussi d'organiser un peu la logistique du transport vers ma propre cérémonie de graduation à la fin de la semaine, quand je sera de retour chez moi : une de mes filles, Calypso, viendra de Québec, et une autre, Amandine, est à Montréal, or la cérémonie est à Sherbrooke et j'arrive de Denver dans la nuit. C'est gérable, mais complexe.


Il y a évidemment beaucoup, beaucoup de gens ici. Nous n'occupons qu'une fraction de cet immense espace, mais c'est une importante fraction qui comprend plusieurs salles de bal. Les organisateurs nous ont préparé une espèce de schéma des lieux, avec répartition des conférences de la journée selon les salles. C'est une bonne idée.

J'ai croisé le toujours sympathique Simon Brand à la table de Microsoft. Il a des autocollants et des tasses avec le logo de Visual Studio, mais le matériel promotionnel n'est pas encore arrivé et le pauvre (il le prend avec humour) a écrit « Microsoft » à la main sur un carton plié en attendant. J'en ai profité pour le remercier d'un coup de pouce qu'il m'a donné il y a quelques semaines quand j'ai eu besoin de modifier la chaîne d'outils de Visual Studio (il semble y avoir un bogue dans le dernier compilateur qui le fait planter – Internal Compiler Error, ICE – sur des fichiers de manière aléatoire quand je compile ContextAA, le fruit de mon doctorat, alors je dois me limiter à l'avant-dernier compilateur pour le moment).

J'ai trouvé l'endroit où se tendra le Keynote de Bjarne Stroustrup (salle de bal, orchestre, quatre écrans géants) et j'ai repéré un endroit sur le bord d'un mur avec une prise de courant; c'est le genre de repérage que je fais systématiquement car je prends beaucoup de notes, ce qui rend la source de courant importante. Herb Sutter est venu me serrer la main; il semble d'excellente humeur. Faut le comprendre : à l'origine, c'est lui qui, à travers la C++ Standard Foundation, a mis Jon Kalb en charge d'organiser cet événement qui est devenu franchement spectaculaire.

Jason Turner et moi bavardons un peu (il habite à vint minutes de voiture d'ici, alors il a aidé à l'organisation de l'événement), Jon Kalb salue la foule et donne l'information la plus importante, soit... les coordonnées du Wi-Fi 😊 Jon Kalb présente l'organisation des lieux, incluant les lieux de relaxation et de discussion, de même que les commanditaires (comme il se doit). Il reste quelques espaces pour certaines périodes de Lighting Talks. Kate Gregory vient ensuite expliquer le code de conduite en vigueur (bravo!), incluant la gestion de l'humour (parfois déplacé), des incidents, l'importance de faire en sorte que toutes et tous se sentent en sécurité, etc.

Enfin, il présente Bjarne Stroustrup qui n'a pas vraiment besoin de présentation ici. Jon Kalb dit que selon lui, C++ n'est pas tant un langage qu'une culture. Une culture d'utilité, de service, d'humilité, de défis. Jon Kalb se dit d'avis que les gens dans la salle aiment les défis. Jon Kalb indique que même les experts de C++ sont humbles, et savent que régler les problèmes complexes du monde contemporain demande parfois des outils plus sophistiqués, plus complexes. Jon Kalb dit que selon lui, C++ repose sur les gens, partout dans le monde, et ici, qui définissent les meilleures pratiques. Il invite les gens à se rencontrer.

Pour la vidéo, voir https://www.youtube.com/watch?v=u_ij0YNkFUs

Pour les diapositives, voir (à venir)

Bjarne StroustrupC++ 20 : C++ at 40

Jon Kalb présente April, qui utilise C++ dans son école secondaire. Nous avons deux étudiant(e)s du secondaire parmi nous, d'ailleurs. April présente Bjarne Stroustrup.

Bjarne Stroustrup prend le plancher. C'est le 40e anniversaire du langage cette année! Mais l'idée est de regarder vers le futur.

Bjarne Stroustrup a fait du sous-titre de sa présentation « Stability and evolution ». Il dit souhaiter placer C++ 20 en perspective. Il rappelle l'état de la technologie en 1979 quand il a débuté ses travaux sur C++. Bjarne Stroustrup montre un vieux téléphone filaire, et relate le rôle de C++ dans la transition vers les téléphones cellulaires plus contemporains.

Cette année est aussi le 50e anniversaire de UNIX. Bjarne Stroustrup reconnaît cet héritage, et rappelle ce sur quoi s'exécutait UNIX à l'époque... en comparant le PDP 11 en question avec les Raspberry Pi contemporains. Ensuite, Bjarne Stroustrup explique que sa présentation regarde vers le futur, et ne s'arrête pas aux détails (qui seront amplement couverts partout cette semaine).

Bjarne Stroustrup recommande de se concentrer sur l'essentiel en expliquant ou en enseignant C++; les détails sont pertinents mais peuvent attendre qu'un besoin survienne. Dire la vérité, juste la vérité, mais... pas tout d'un coup! Il recommande aussi de distinguer ce qui est légal de ce qui est efficace, et fait un plaidoyer pour des outils de qualité (par exemple, les Core Guidelines).

Concevoir un langage n'est pas la même chose que développer un produit. Le monde est complexe, diversifié, parfois messy, il faut être pragmatiques. Souvent, seul C++ peut faire le travail, mais il faut que le langage demeure assez simple pour être utilisé au quotidien. On ne vise pas un idéal de pureté, et il ne faut pas être expert-only.

Bjarne Stroustrup explique que C++ évolue, depuis le début : il a fallu commencer humblement et supporter une forme d'adoption graduelle. Le principe de Zero Overhead demeure (you don't pay for what you don't use; what you do use you could not have hand-written better); on vise à rendre les choses simples plus simples à faire. Il faut aussi « viser haut » et changer les manières de penser. Quand on réussit, ce qu'on a construit est durable.

Bjarne Stroustrup dit que la valeur d'un langage se reflète dans la qualité de ses applications. C++ a changé le monde; c'est objectivement un succès. Le langage permet de bien exprimer les idées, de mieux utiliser le matériel, d'écrire des compilateurs de haute qualité, et est utilisé dans une vaste gamme de domaines (partout, vraiment).

Bjarne Stroustrup rappelle quelques règles de base (Rules of Thumb) de C++ :

Il y a un plan, et il faut que le langage demeure cohérent.

Le système de types statique aide à la détection des erreurs, une chose importante, et mène à une « performance » plus élevée. La surcharge de fonctions, d'opérateurs, la programmation générique, etc. apportent de la souplesse.

Le support uniforme pour tous les types permet de programmer plus efficacement à l'aide d'abstractions. D'ailleurs, C++ est une abstraction de la machine : plusieurs opérations correspondent directement à ce que supporte le matériel, les tableaux modélisent la mémoire, etc. Les abstractions comme bitset<N> ou span<T>, couplées à l'inférence de types que nous apporte CTAD, contribuent à cet avantage.

Bjarne Stroustrup mentionne le « principe de l'oignon » : plus on enlève des pelures, des strates, et plus on pleure.

Pour la gestion des ressources, Bjarne Stroustrup mentionne la gestion à l'aide des portées. Toute ressource devrait avoir un(e) propriétaire, un(e) responsable. Il importe de contrôler la totalité du cycle de vie d'un objet (création, destruction, mouvement, copie). Il existe plusieurs types de ressources; la collecte d'ordures, limitée à la gestion de la mémoire, est insuffisante.

Bjarne Stroustrup associe la jonction de composants pour former un tout cohérent à l'avènement des modules. L'ordre des importations n'est pas important (contrairement aux #include qui font de l'inclusion lexicale et nous viennent de C), et les modules supportent un paradigme de programmation plus « propre ». Il n'existe qu'une seule copie de chaque module, et chaque module n'est analysé qu'une seule fois. La composition est essentielle; l'alternative est de répliquer, de dupliquer : on compose avec des modules, des classes, des fonctions, etc.

Bjarne Stroustrup arrive à la programmation générique : écrire du code qui respecte des requis abstraits. Les concepts de C++ 20 sont un immense pas en avant dans ce sens. Les détails n'ont pas à être explicités, ils sont inférés des définitions. La programmation générique, c'est simplement de la programmation. De la programmation composable, paramétrable, généralisable.

La programmation orientée objet suit : capacité de concevoir des hiérarchies de classes, support de classes abstraites, accès indirects, etc. Le recours à des pointeurs intelligents réduit les risques de fuites. Bjarne Stroustrup montre que variant peut moderniser des pratiques des années '70 et '80 de manière très avantageuse. Il note au passage que std::overloaded() ne sera pas dans C++ 20 (c'est une question de temps).

Pour ce qui est de l'utilisation directe des ressources du système, Bjarne Stroustrup discute des outils permettant la concurrence. Il mentionne les nouveaux jthread au passage, et le recours aux stop_token (je pense qu'il y avait une erreur dans sa diapo sur le sujet). Les algorithmes partagés sont mentionnés. Bjarne Stroustrup mentionne que certains (p. ex. : ranges::sort()) n'ont pas été prêts pour C++ 20, mais heureusement C++ est extensible et nous pouvons pallier cela aisément.

Bjarne Stroustrup poursuit en discutant des critiques, et de l'évolution du langage (ajout d'outils, ajustements du langage lui-même). C++ est paramétrable, configurable, ajustable. Bjarne Stroustrup insiste sur l'importance de réfléchir à haut niveau le plus possible, et de descendre plus près de la machine seulement quand c'est nécessaire (de manière mesurable). Il relate un programme hautement optimisé pour un PDP 11 mais qui, une fois porté sur un Cray qui était plus de 100 fois plus puissant, devenait 16 fois plus lent.

La programmation à la compilation, lorsque possible, est précieuse : constexpr, les templates (variadiques ou pas) et autres consteval font partie de ce qui rend C++ si puissant. Le système de types extensible de C++ permet d'appliquer ces techniques aux types des usagers.

Bjarne Stroustrup revient sur le support direct du matériel pour expliquer les coroutines. Il montre un joli exemple de générateur (générer une séquence infinie, filtrer les non-premiers, prendre le 10'000 premiers) avec du code vraiment très simple. On voit bien ce qu'apportent les coroutines à la composabilité du code. Il montre au passage qu'il est parvenu à généraliser la solution avec un using si discret qu'on ne l'a presque pas vu.

Ensuite, Bjarne Stroustrup parle de l'importance de combiner tous ces mécanismes. Créer des bibliothèques. Selon lui, un usager ne devrait pas devoir se demander si un mécanisme fait partie du langage ou de la bibliothèque; la bibliothèque standard est un exemple, et nous avons besoin de plus de bibliothèques de qualité. Il mentionne que cppreference a une liste de bibliothèques de qualité (cool!)

Bjarne Stroustrup parle de chrono, qui ajoute maintenant les dates et les fuseaux horaires. C'est vraiment un chef-d'oeuvre, ce truc. Un programme de quelques lignes par Howard Hinnant génère une cédule correcte pour les rencontres de WG21. Wow!

Bjarne Stroustrup nous dit qu'il n'a pas parlé de trucs de bas niveaux (pointeurs et autres). Il est possible d'écrire du code C++ efficace, portable et sécuritaire à l'aide du C++ standard.

La plupart des règles dont Bjarne Stroustrup a parlé aujourd'hui sont... vieilles, souvent aussi vieilles que le langage lui-même. Les besoins fondamentaux en programmation demeurent les mêmes. Avec C++ 20, nous avons la meilleure approximation des idéaux de C++ à date, mais le chemin se poursuit. C++ n'est pas qu'un semble de mécanismes : c'est une communauté, un processus évolutif, une philosophie.

Bjarne Stroustrup parle de C++ 23 (réflexivité statique, réseaux, exécuteurs, etc.), puis revient à C++ 20, pour parler du processus de votation qui est en cours.

Q : où en sont les exécuteurs?

Bjarne Stroustrup : (j'ai manqué la réponse)

Q : le code hérité (legacy code) est souvent vieux. Je vois le nouveau code qui est superbe. Comment aider à apporter le changement?

Bjarne Stroustrup : le code hérité est un vrai problème. On en a accumulé beaucoup. La documentation est souvent désuète ou disparue. Je suggère (a) d'utiliser le code moderne pour les nouveaux composants, et (b) de remplacer les vieux systèmes graduellement. Il nous faudra de meilleurs outils pour faciliter la modernisation du code existant. Avoir des problèmes de code hérité, cela dit, est un signe que le langage a été un succès. Il y en a beaucoup en C++... parce qu'il y a beaucoup de code C++, tout simplement.

Q : quel est le mécanisme de C++ qui a eu le plus grand impact traditionnellement sur le langage? Et avec C++ 20?

Bjarne Stroustrup : je triche avec deux dans chaque cas. Récemment, c'est les fonctions constexpr. La partie invisible est le support de la programmation concurrente. Avec C++ 20, ce sera les concepts, mais la partie invisible est les modules, qui permettent la suppression de « dépendances dégoûtantes ».

Q : on paie parfois pour des mécanismes qu'on n'utilise pas, par exemple les graphiques ou les fuseaux horaires, quand bien même ce ne serait qu'en temps de développement.

Bjarne Stroustrup : ... quelqu'un doit payer, éventuellement. Mieux vaut que les usagers en bénéficient. Le travail des quelques implémenteurs bénéficient à la communauté dans son ensemble.

Q : la responsabilité et la prise en charge des ressources est importante en C++, mais n'est pas imposée dans le langage comme Rust le fait.

Bjarne Stroustrup : cela briserait le code existant. Je préfère les Coding Guidelines est des outils. Vous pouvez le faire dans le langage, mais je ne pense pas que le langage l'imposera.

Q : dans un nouveau projet, devrions-nous éviter les classes abstraites?

Bjarne Stroustrup : il est rare qu'on débute vraiment un projet à partir de rien. Il y a des domaines où la POO traditionnelle est une bonne solution. Cela dit, mieux vaut analyser le problème d'abord, plutôt que d'y aller avec des croyances.

Hana Dusíková est passée me voir alors que je bavardais avec Gabriel Aubut-Lussier et Jason Turner. Elle a rempli le « bingo de CppCon » pendant la présentation de Bjarne Stroustrup et a coché quatre des cases déjà. Elle m'a montré avec fierté (et elle a bien raison!) ses dernières mesures comparatives de vitesse pour le traitement des expressions régulières (d'autres langages, les implémentations de C++ – utiles, mais pas rapides – et les siennes, d'une rapidité stupéfiante).

Je prends un yogourt aux fraises, une pomme et un peu de café, puis je pars à la recherche de toilettes... Il y en a beaucoup, mais nous sommes si nombreux que même en marchant très, très loin (le bâtiment est gros comme un quartier de banlieue!), il y a encore des files d'attente.

Je me déplace ensuite là où Bryce Adelstein Lelbach donnera sa présentation. Truc moche : grande salle, pas d'alimentation électrique...

Pour la vidéo, voir (à venir)

Pour les diapositives, voir (à venir)

Bryce Adelstein Lelbach – The C++ 20 Synchronization Library

Bryce Adelstein Lelbach est un ami de WG21 et un des organisateurs de l'événement. C'est aussi un des programmeurs experts chez NVidia. Ça devrait être intéressant ce matin...

JF Bastien m'accroche au passage car je suis assis à l'arrière, et qu'il souhaite un peu de solidarité. Il a bien raison, on s'en va à l'avant de la salle 😊

Bryce Adelstein Lelbach présentera de nouveaux outils pour la synchronisation lors de l'exécution de programmes concurrents. Sa première diapo... n'a rien à voir avec le contenu de la présentation.

Bryce Adelstein Lelbach utilise des raccourcis pour std::ranges et std::views car sinon, ça devient lourd.

Bryce Adelstein Lelbach relate son historique de travail avec HPX. Il parle de la recette pour un runtime concurrent réussi : worker threads, files concurrentes multiples consommateurs/multiples producteurs, un système de détection de terminaison, et des algorithmes parallèles.

Les worker threads peuvent être modélisés par un thread_group auquel on injecte des fonctions à exécuter. Bryce Adelstein Lelbach parle du problème de la jonction des threads avant destruction. Le mécanisme pour détecter la fin passe par une atomique aux opérations relaxées. Il mentionne ensuite les types jthread et stop_token qui simplifient ce modèle. L'API permet de demander (requête, pas obligation) un arrêt d'exécution. Le trio std::stop_source / stop_token / stop_callback (analogue à une continuation) aide à paramétrer son comportement. Il sera possible pour condition_variable d'attendre sur un stop_token. Le thread_group est présenté avec ajustement, c'est joli.

La file concurrente (de capacité finie) présentée repose sur un std::queue<T> et un std::mutex, de même que deux std::counting_semaphore (avec services try_acquire(), try_acquire_for(), try_acquire_until() et, bien sûr, acquire() et release()). Il utilise deux sémaphores, soit un pour les objets produits et un autre pour l'espace restant. Il montre les services de sa file concurrente, et la synchronisation impliquée. Il y a une danse intéressante entre les deux sémaphores dans son implémentation.

Bryce Adelstein Lelbach critique un peu le recours au mutex pour synchroniser la file, indiquant que c'est un outil un peu lourd dans les circonstances pour des systèmes à base latence. Il construit un spin lock autour d'un atomic<bool>, mais discute de la contention. Il montre qu'on peut utiliser atomic_flag, mais préfère atomic<bool>. Son spin_mutex officiel est présenté, mais il est plus subtil (il y a un contrôle à l'interne sur la base d'un mécanisme de back-off en fonction du nombre de tentatives d'accès échouées). Le code présenté a des bogues, mais Bryce Adelstein Lelbach veut vraiment nous présenter la nouvelle API de wait-notify des atomiques (wait(), notify_one(), notify_all()). Quelques manières par lesquelles il est possible des les implémenter sont proposées.

Bryce Adelstein Lelbach mentionne que atomic_flag est légèrement amélioré maintenant.

Bryce Adelstein Lelbach présente un ticket_mutex qui lui semble plus honnête que les alternatives plus naïves. Ça modélise un ticket numéroté à la charcuterie. Il utilise les mécanismes standards requis pour éviter le faux-partage.

Pour la détection de terminaison, Bryce Adelstein Lelbach construit un gestionnaire de tâches avec un plafond sur le nombre de tâches. Il réinvestit le thread_group pour ce faire. Il règle un bogue de mauvaise gestion de fin de traitement avec un latch. Il en profite pour expliquer std::latch, une sorte de point de rendez-vous (count_down(), arrive_and_wait(), try_wait(), wait(); on a une API asynchrone ici).

Bryce Adelstein Lelbach présente submit_tree(), qui crée une arborescence binaire de tâches... et finit par bloquer la file plafonnée dû à l'épuisement des ressources. Le boost blocking intervient, pour garantir une progression. Ça se fait manuellement (forcer le traitement de tâches quand on ne peut plus en insérer).

Bryce Adelstein Lelbach poursuit avec les algorithmes parallèles. Il en profite pour présenter les politiques d'exécution (execution_policy), qui indique entre autres la taille des blocs à traiter (chunk_size()). Il fait un histogramme parallèle. Son execution_policy a une méthode submit() qui accepte une fonction et prend en charge son exécution. Il parle de la synchronisation en sortie. Il utilise atomic_ref pour cela (je demande à JF Bastien si c'est coûteux, mais il dit que c'est pas si mal).

Bryce Adelstein Lelbach examine ensuite exclusive_scan(). Son exemple utilise du texte (bonne idée, c'est plus clair qu'avec des chiffres). Il montre une technique d'implémentation (upsweep, downsweep). Il en profite pour utiliser et présenter un std::barrier et un std::latch. Pour std:barrier, on a une fonction qui sert de CompletionFunction, et qui sera appelée suivant le rendez-vous de l'ensemble des tâches. L'API comprend arrive(), wait(), arrive_and_wait() et arrive_and_drop().

Bryce Adelstein Lelbach  présente un comparatif entre std::latch et std::barrier. Il se trouve que barrier::arrive() retourne un arrival_token. Il suit avec un inventaire des nouveaux outils de synchronisation, présentés aujourd'hui.

Q : est-ce que execution_policy et executor sont une seule et même chose?

Bryce Adelstein Lelbach : je ne veux pas répondre à cette question >rires!<

Q : est-ce que ton exclusive_scan() est échelonnable?

Bryce Adelstein Lelbach : il est pas mal mais pas parfait (il nomme un meilleur algorithme, mais dit qu'il ne tient pas sur une diapo)

Q : si un thread verrouille compteur sur un ticket_mutex, quelle sera la conséquence?

Bryce Adelstein Lelbach : ça va mal se passer

Q : peux-tu expliquer le mécanisme d'annulation d'un jthread?

Bryce Adelstein Lelbach : c'est complexe. Ça ressemble à la relation entre une future et une promise

Q : existe-t-il une implémentation utilisable sur un autre compilateur?

Bryce Adelstein Lelbach : pas tout à fait (il y a un enjeu politique)

Q : pourquoi est-ce que wait / notify sur une atomique serait plus efficace que sur un mutex?

Bryce Adelstein Lelbach : les mécanismes traditionnels sont plus lourds (JF Bastien dit que c'est un mécanisme pour implémenter des condition_variable et des mutex)

Q : est-ce que mutex va être modifier pour accoter des nouveaux mécanismes?

Bryce Adelstein Lelbach : j'en doute

(quelques questions spécifiques sur les opérations raisonnables à faire dans tel ou tel contexte s'ensuivent; je n'ai pas tout noté)

Bryce Adelstein Lelbach a travaillé fort, et il a parlé vite 😊 Je suis ensuite allé me prendre quelque chose à manger. Il y a des concessions avec sandwich et salade, mais aussi des repas chauds. J'ai pris un plat de riz mexicain avec fèves noires, poulet, porc, fromage, salsa verde. C'était bon, et c'était un peu lourd, mais à 14 USD c'était un bon rapport qualité / prix en comparaison avec les alternatives. J'ai bavardé avec Jean-Luc, qui était dans ma classe l'an passé et qui était à côté de moi dans la file, et nous sommes allées ensemble vers le Trainers Panel par la suite.

En marchant, j'ai croisé mon ami Walter Brown, pour qui j'ai un immense respect. Ça m'a permis de lui dire à quel point les gens l'avaient en haute estime (hier, en bavardant avec les participant(e)s qui en étaient à leur première présence ici et en suggérant des présentateurs d'exception, son nom était sorti tout en haut de la liste). Il a semblé touché. Tant mieux; il le mérite bien!

Jon Kalb – Trainers Panel 1

Jon Kalb anime un panel où l'on trouve Stephen Dewhurst, Ben Saks, Dan Saks (que je respecte tout particulièrement, et avec qui chaque conversation est un petit trésor de sagesse) et Klaus Iglberger. J'ai mangé en écoutant les échanges (c'est intéressant, mais j'ai été sur scène ici pour des panels semblables dans le passé; j'écoute en souriant et je note quelques idées inspirantes et intelligentes ici et là, car ce sont tous des gens brillants et des formateurs d'expérience.

Il y a plein de perles, évidemment. Quelques-unes:

J'en profite à la fin de la présentation pour saluer mon ami Dan Saks et prendre un peu de ses nouvelles. Il est toujours aussi vif d'esprit, même si la retraite est quelque chose qu'il semble contempler à l'horizon. Jon Kalb poursuit la tradition et distribue les chocolats aux gens qui, comme moi, participent à l'organisation ede l'événement (mioum!).

Je me déplace vers la salle où Michael Wong et Gordon Brown vont présenter. Petit bavardage avec Staffan Tjernström et John Plaice, salutations cordiales avec l'ami Michael Wong à son arrivée, et on commence. La salle se remplit; je jase brièvement avec Rob Irving de CppCast.

Pour la vidéo, voir https://www.youtube.com/watch?v=F4GzsA00s5I

Pour les diapositives, voir (à venir)

Michael Wong et Gordon Brown – Writing Safety-Critical Automotive C++ Software for High Performance AI Hardware

Michael Wong est seul sur scène et prépare une vidéo qu'il souhaite nous présenter. On commence avec un léger retard.

Michael Wong dit vouloir montrer en quoi C++ sert dans de nombreux domaines d'application. Comme d'habitude, la page qui décrit son pedigree est... longue, complexe, et écrite en petits caractères 😊

Michael Wong doit vouloir parler de programmes sécuritaires, de divers standards de qualité et de sécurité, et de SG12.

Michael Wong indique que pour réaliser la conduite autonome, une variété de processeurs spécialisés (GPU, IA) doivent réaliser des calculs. C'est un marché dominé par Python et C++.

Michael Wong présente SAE J3016, une gradation de niveaux de conduite autonome (échelle de 0, danger, à 5, automatisation complète). Il dit que le niveau le plus difficile n'est pas le niveau 5, mais bien le niveau 3 (automatisation conditionnelle), celui où la conduite autonome doit prendre une décision trop risquée et passer le relais à un humain. Michael Wong pense que ce niveau est un pire cas, et ne sera jamais implémenté.

Michael Wong présente quelques cas d'espèces (voiture de Google, Tesla, d'autres), puis présente ce qu'il faut pour qu'un véhicule autonome puisse accomplir sa tâche : localisation, cartographie, comprendre la scène, détection des pannes (incluant les résultats en retard : système en temps réel), et identification d'une état stable et sécuritaire vers lequel converger. Michael Wong parle des standards ISO 26262 (Functional Safety of Road Vehicles) et un autre que je n'ai pas le temps de noter. Malgré tout, il y a des accidents, et c'est pas amusant (la vidéo nous le montre) :

Il y a aussi beaucoup d'histoires heureuses, incluant un véhicule qui a transporté son « conducteur » à l'hôpital alors qu'il faisait une crise cardiaque.

Michael Wong présente le pipeline de traitement usuel d'un véhicule intelligent. Il y a beaucoup de données qui circulent entre les capteurs (plus qu'un TB par mois, par véhicule. Selon lui, même la 5G ne suffit pas pour compenser. Il se dit d'avis que des processeurs spécialisés pour l'IA seront nécessaires. Cela explique son intérêt pour SG19.

Michael Wong utilise l'acronyme SOTIF, pour Safety of the Intended Function. Ça rejoind ISO PAS 21448 (Safety of the Intended Functionality) et SAE J3601 (Cybersecurity). Une discussion des enjeux et des risques de sécurité s'ensuit. Il a de superbes photos de cas pathologiques. Par la suite, il trace la différence entre un standard de qualité comme les Coding Guidelines (faites mieux que ce seuil et vous aurez du code de qualité), et un standard de sécurité comme les Safety Guidelines (faites mieux que ce minimum et vous ne briserez rien). Une longue liste de Safety-Critical APIs suit.

Michael Wong discute ensuite de MISRA, qui se limite à des règles vérifiables par programmation, mais qui remonte à 2008... basé sur C++ 98. Il y a plein de trucs de C++ 11 et plus récent qui n'y sont pas considérés.

Autosar est un autre standard pré-C++ 11 qui vise une modernisation. Il est difficile de choisir un bon standard avec toutes ces propositions vieillissantes. Plusieurs standards ont des règles en commun; il y a un noyau commun qui semle envisageable.

Bonne nouvelle : même Autosar semble avoir accepté qu'il soit préférable d'accepter la gestion de la mémoire, et ce, partout. A-t-on besoin de mémoire allouée dynamiquement? Michael Wong donne plusieurs raisons. L'importance de contrôler new et delete est limpide, incluant des allocateurs avec WCET déterministe.

Michael Wong suit avec une présentation de SG12 et de son rôle. Autosar semble destiné à fusionner avec MISRA. SG12 collabore maintenant avec WG23. Michael Wong pense que MISRA va se joindre au groupe dès la rencontre de Belfast. Il ajoute qu'il y a convergence de standards en ce sens, incluant même Vulkan (un standard graphique, qui se transforme en standard de programmation général).

Michael Wong fait le tour de ce qui manque. Le gros morceau : tous ces standards se limitent pour l'essentiel au code séquentiel (pas de code concurrent ou parallèle, pas de code hétérogène). Il rapporte un problème d'Audi avec accélération défectueuse, le tout résultant d'une globale accédée concurremment (une Data Race).

Michael Wong vise une convergence dans un horizon proche. C'est tout un contrat.

Q : je suis le Chair d'un standard de sécurité. On a de la difficulté avec MISRA qui est un organisme privé. Le comité de C est ISO. 7961 cherche à intégrer MISRA, mais on préférerait que WG14 travaille avec MISRA d'abord, puis que le standard ISO soit adopté.

Michael Wong : en effet, MISRA est un organisée très privé. Ça ne coûte pas cher pour adhérer, mais ils souhaitent rester petits. Je note que les groupes de Safety Critical sont particuliers : tout le monde veut ces standards, mais personne ne veut les utiliser.

Q : quelle est la relation entre la sécurité et le parallélisme ou les systèmes hétérogènes?

Michael Wong : non-déterminisme, communication, transformation des données... Il y a tellement de risques supplémentaires!

Q : peut-on avoir un exemple de règles?

Michael Wong : j'en ai donné une ou deux tantôt (un if...else if... doit finir par un else, par exemple). C'est quelque chose de facile à lire

Q : je trouve difficile de reproduire des bogues dans des systèmes hétérogènes...

Michael Wong : oui. C'est une vraie difficulté. On manque d'outils et de techniques pour nos tests.

Michael Wong est une machine. C'est fou de voir à quel point, en peu de temps, il a réussi à réunir des acteurs de divers milieux pour travailler ensemble sur des enjeux d'envergure considérable. Je vais lui écrire un petit mot de félicitations tantôt.

Je commence à avoir un peu mal à la tête (trop de café, pas assez d'eau), alors je me suis pris un verre de cubes de glace à siroter. Je marche vers la salle de bal où Gabriel Dos Reis va présenter un guide de programmation à l'aide de modules, car je m'intéresse à la pédagogie de ce nouveau mécanisme. En marchant, je croise quelques québecois (toujours agréable!), et un prof de l'université de Washington m'intercepte, curieux de connaître mon plan pour demain matin. On échange un peu sur mon plan de match, et il semble enthousiaste. J'espère qu'il viendra, car je ne sais pas comment les gens vont réagir à ma proposition.

Pour la vidéo, voir https://www.youtube.com/watch?v=tjSuKOz5HK4

Pour les diapositives, voir (à venir)

Gabriel Dos Reis – Programming with C++ Modules: Guide for the Working Software Developer

Gabriel Dos Reis prend le plancher.

Gabriel Dos Reis présente les modules comme une nouvelle approche à l'organisation logicielle en C++. Il trace un historique avec les pratiques héritées de C, en comparaison avec les usages en C#, Java ou d'autres langages où le modèle de réutilisation repose sur des unités compilées plutôt que sur de l'inclusion lexicale.

Gabriel Dos Reis donne du vocabulaire : un progamme est une collection de fichiers sources traduits individuellement; une unité de traduction communique en affichant des déclarations non-vérifiées provenant de sources externes, etc. Il poursuit en traçant un historique de ses propres travaux, reconnaissant qu'on est partis de loin il y a quatre ou cinq ans. Il montre cette belle photo de lui et Richard Smith se serrant la main à Kona 2019, et remercie les contributeurs sur plusieurs années de même que la communauté dans son ensemble pour l'appui accordé à ses trabaux.

Gabriel Dos Reis enchaîne avec ce qui a été accompli : des structures langagières pour supporter les composants, l'isolation, un meilleur débit de génération de code, et des outils de développement plus riches sémantiquement. Nous avons aussi un chemin de transition, sous la forme de fragments du module global et d'unités d'en-tête (Header Units).

Une définition de module a la forme :

export module Plan.Figures;
#include <cmath>
export struct Point {
   int x;
   int y;
};
export struct Rectangle {
   Point ul;
   Point lr; 
};
export int width(const Rectangle &rect) {
   return std::abs(rect.ul.x - rect.lr.x);
} // etc.

... et pour le code client :

#include <iostream>
import Plan.Figures;
int main() {
   Rectangle rect{ { 0,0 }, { 1,1 } };
   std::cout << width(rect) << std::endl;
}

Gabriel Dos Reis décrit le fonctionnement du mécanisme. Chaque compilateur a sa propre stratégie d'implémentation. Utiliser une fonction non-exportée est une erreur au point d'utilisation.

Gabriel Dos Reis parle ensuite d'un pImpl efficace. Un module peut avoir des sections privées, pour usage interne seulement. Ensuite, il présente la distinction entre module et fichier : un module peut avoir une interface et une implémentation physiquement séparées l'une de l'autre, et peut mêem avoir plusieurs fichiers d'implémentation pour une interface donnée. Le module est une entité logique distincte du concept de fichier.

Gabriel Dos Reis montre comment une interface de module peut être répartie sur plusieurs fichiers sources. Cela se fait à l'aide de partitions :


export module Plan.Figures;
export import :PartiePoint;
export import :PartieRect;
export module PlanFigures:PartiePoint;
export struct Point {
   int x;
   int y;
};
export module PlanFigures:PartieRectangle;
import :PartiePoint;
#include <cmath>
export struct Rectangle {
   Point ul;
   Point lr; 
};
export int width(const Rectangle &rect) {
   return std::abs(rect.ul.x - rect.lr.x);
} // etc.

Q : quel est l'intérêt d'utiliser des partitions plutôt que des modules distincts?

Gabriel Dos Reis : ça évite d'avoir des tas de petits modules avec des fonctionnalités similaires.

Gabriel Dos Reis parle ensuite d'agrégation de modules (avec export import) : on prend des parties de divers sous-modules et on forme, par importation puis exportation, un module synthétique plus complexe.

Le sujet qui suit est celui du chemin de transition, à partir de fragments du module global. Faut gérer les macros et leur effet sur les inclusions lexicales... On peut écrire module; tout simplement pour insérer un fichier dans le module global à titre de fragment. Une autre technique est de projeter une vue modulaire sur un en-tête :

module;
#include <sys/stat> // disons
export module Nom.Module;
namespace Sys {
   export using ::stat;
   export using ::chmod;
   // etc.
};

Une unité d'en-tête est un presque module :

#import <iostream>; // oui, ça marche
import Plan.Figures;
int main() {
   using namespace std;
   Rectangle rect { {0, 0}, { 1, 1 } };
   cout << width(rect) << endl;
   // ...
}

On peut donc faire une vue modulaire à partir d'un agrégat d'en-têtes. Conséquence : les macros ne sont pas exportées!

export module gdr.std.core; // disos
export import <string>;
export import <vector>;
export import <algorithm>;
// etc.

Gabriel Dos Reis recommande de ne conserver #include que pour les en-têtes qui sont un peu sales (exposent des macros dont on a besoin).

Gabriel Dos Reis en arrive à l'isolation :

La sémantique associée à une interface de module y est fixée et figée lors de la génération du code. Un bon côté de ce modèle est que l'ordre d'importation des modules n'a pas d'importance, et que les importations ne sont pas transitives. Gabriel Dos Reis recommande l'organisation de fichiers suivante :

Gabriel Dos Reis aborde ensuite la question de l'impact des modules sur l'écosystème de C++ : ils ont un impact sur les systèmes de génération de code, les analyseurs de code, les environnements de développement, le matériel pédagogique, etc... le langage dans son acception du XXIe siècle. Les modules vont être livrés avec MSVC, gcc et clang.

Q : composer un module à partir d'en-têtes rend-il les en-têtes précompilés obsolètes?

Gabriel Dos Reis : on souhaite effectivement les faire disparaître

Q : quels sont les gains en termes de vitesse de développement sur du code réel?

Gabriel Dos Reis : les .pch sont Memory-Bound, et sont très rapides. Avec WinRT, on voit un gain par un facteur de 10 sur des .h, et on est un peu plus lents que les .pch. Notez que nos modules sont encore très naïfs et pas vraiment optimisés. Notez aussi que les modules sont dix fois plus petits que les .pch équivalents.

Q : doit-on compiler manuellement les modules dans le bon ordre?

Gabriel Dos Reis : ça dépend des implémentations, mais on travaille là-dessus.

Q : y a-t-il une raison technique pour séparer l'interface de l'implémentation?

Gabriel Dos Reis : vous pouvez tout mettre dans le même gros fichier, mais ça va être difficile à lire.

Q : dans les .DLL, comment gère-t-on la visibilité des import et des export?

Gabriel Dos Reis : ça dépend des plateformes. Chez Microsoft, c'est géré par le compilateur. C'est pas la même chose que __declspec(import) par exemple, qui touche l'édition des liens. On a toutefois une nouvelle notion de Module Linkage, qui ouvre de nouvelles options d'optimisation

Q : pourquoi n'y a-t-il pas de lien entre module et namespace?

Gabriel Dos Reis : ça ne fonctionne pas bien avec le langage; il n'y a pas de fermeture dans un namespace, c'est toujours ouvert pour extension.

Q : qu'en est-il de la visibilité en lien avec les namespace?

Gabriel Dos Reis : avec export, ODR est garanti à la compilation; on n'a plus besoin de l'éditeur de liens.

On a aussi discuté de trucs en lien avec les outils, mais je n'ai pas tout noté. Il y avait des crudités et des trempettes (hummus, mais aussi un yogourt à l'aneth et une sauce crémeuse ail et parmesan vraiment très bien), alors j'ai mangé une petite bouchée. Je me suis re-servi de la glace, un peu de citron, puis je me suis dirigé vers la salle où John Lakos présentera. Michał Dominiak m'a rappelé que je dois aller au souper des étudiant(e)s tantôt. J'ai croisé le toujours sympathique Gordon Brown, et on a échangé quelques minutes (ses travaux rejoignent de près les miens).

Les salles de bains ici viennent en trois déclinaisons, soit homme, femme et Gender-Neutral (le symbole est un rond bleu avec un triangle blanc à l'intérieur). C'est une bonne chose car la communauté se diversifie de plus en plus.

Pour la vidéo, voir https://www.youtube.com/watch?v=ebn1C-mTFVk

Pour les diapositives, voir (à venir)

John Lakos – Value Proposition: Allocator-Aware (AA) Software

John Lakos est un présentateur très rigoureux, et typiquement très riche en contenu. Je vais essayer de prendre des notes efficaces malgré le fait qu'il tend à passer plusieurs diapos par minute.

John Lakos nous avertit qu'il a beaucoup de contenu (une heure trente, mais il n'a qu'une heure pour présenter) alors il va y aller rapidement et nous avertit que ça risque de déborder un peu. Il nous invite à aller aux autres présentations sur les allocateurs cette semaine. John Lakos nous dit aussi qu'il a terminé son livre, et qu'il sera en vente à Noël. On l'applaudit.

Le propos est que les allocateurs locaux offrent de la performance, mais entraînent des coûts d'entretien. Il y a plusieurs avantages collatéraux aussi à utiliser des allocateurs, mais il y a aussi du F.U.D. autour de ce sujet. Il compte séparer les craintes imaginaires et les vrais ennuis. Mettre en place des allocateurs maison est coûteux; on a le maximum de performance, mais faut le développer et le mettre en oeuvre.

John Lakos trace une analogie avec les compagnies d'aviation : un grand espace pour la classe économique, un petit espace de première classe. Il y a toujours un point où le besoin enraînera la pulsion d'écrire son propre allocateur. Il y a des bénéfices et une utilité avec les outils simples, et il y a des coûts pour les efforts plus importants. On ne veut pas investir tout cet effort, tout le temps; faut que ça vaille la peine. Ensuite, il y a la classe affaires, qui est entre les deux, et où on peut avoir un bon rapport qualité / prix, et une classe Premium Economy qui est presque la classe affaires. Il y a un espace pour les avantages incrémentaux mais non-critiques.

John Lakos revient sur ce schéma qu'il nous a présenté de manière incrémentale, mais d'un trait. C'est indigeste, et on blague

TIMTOWTDI (Tim Toady). On a trois modèles, soit C++ 11, C++ 17 (PMR) et BB20V (Bloomberg 2020 Vision). C++ 11 est Compile-Time Centric. Il n'a pas de surcoût, permet le partage de mémoire, mais exige des templates et est peu utilisé. BDE est Runtime-Centric (Bloomberg), il n'a presque pas de surcoût, mais il a un coût de développement. PMR est basé sur BDE, mais plus idiomatique à C++, et devrait remplacer BDE. Il y a un support langagier pour PMR : une annotation guidera le travail du compilateur, on générera beaucoup de code, et les allocateurs seront injectés. Les performances sont semblables, et on s'améliore.

John Lakos parle des bénéfices en termes de « performances » : on alloue plus rapidement, on libère plus rapidement, on a une meilleure localité d'accès. Pour mesurer le premier aspect, il faut désactiver le second (impact trop grand). Sur une courte période, la vitesse d'allocation compte; sur une longue période, la localité d'accès domine totalement. Un autre modèle commun est d'allouer / de libérer des blocs de taille semblable, ce qui suggère le recours à plusieurs allocateurs spécialisés. Un autre cas d'utilisation est la capacité de libération en blocs (plus rapide, moins de fragmentation). Un allocateur pris en charge peut aussi être utile.

Les allocateurs locaux simplifient la multiprogrammation, surtout si on alloue dans une zone non-partagée!

John Lakos rappelle qu'utiliser des allocateurs n'est pas un job de débutant, mais pas nécessairement un job d'expert.

Q : que font les allocateurs commerciaux?

John Lakos : ils font de leur mieux, mais ce sont des allocateurs globaux, et ça a ses limites.

John Lakos aborde ensuite la question des coûts : créer les allocateurs, les entretenir. Il trace un lien entre être const-aware et être allocator-aware, au sens où la propagation de cette intelligence est importante. Il y a aussi des coûts incrémentaux à exploiter les composants allocator-aware... ou à les ignorer. Ces trucs sont faciles à utiliser, en général, mais subtils à développer. Convertir une classe pour y injecter du allocator-awareness implique ajouter un trait; c'est du travail mécanique, mais c'est du travail. Ajouter un allocateur à un conteneur demande d'ajuster plusieurs méthodes. Toucher à des trucs comme pair et shared_ptr est douloureux.

John Lakos parle de 10% de code Boilerplate à ajouter dans certains cas. C'est as négligeable. Il y a aussi un coût d'opportunité, au sens où on doit y dédier une programmeuse ou un programmeur. Il mentionne un outil d'automatisation nommé bde_verify qui peut servir à titre d'analyseur statique. Chez Bloomberg, le développement de tout cela a coûté un montant somme toute significatif. Il trace une analogie avec les voitures autonomes; une fois le coût du développement absorbé, le logiciel est là, et on peut l'utiliser. Et si on n'en a pas besoin, on n'a qu'à ne pas s'en occuper (il reste un fardeau cognitif dans la signature du code, bien sûr).

John Lakos parle ensuite des coûts associés à une utilisation inappropriée. Que faire, par exemple, si l'objet survit à la mort de son allocateur? Ça arrive rarement (faut faire exprès, mais ça pourrait arriver avec un shared_ptr par exemple), mais quand même... Plus probable : choisir un allocateur inapproprié, ou mal utiliser un allocateur. John Lakos aborde la comptabilité (ou pas) de ces mécanismes avec le code C++ moderne (p. ex. : les λ). Il faut des constructeurs non-triviaux; ls allocateurs interagissent de manière déplaisante avec la sémantique de mouvement, etc. Il y a aussi plusierus coûts politiques (adoption par les patron(ne)s, par exemple).

John Lakos met de l'avant les plus, une performance accrue, et les moins, des coûts. Quelle est la proportion de code qui profite des allocateurs? John Lakos dit que nous ne le savons pas, mais il y a des avantages et il faut réduire le facteur « douleur ». Les allocateurs ultra pointus rapportent moins, malgré leurs avantages manifestes sur le plan technique, que els allocateurs destinés à usage général.

John Lakos mentionne sur les allocateurs de type BDE peuvent s'enchaîner; ils sotn composables. Si l'un d'eux échoue, il peut déléguer à un plan B. Ça permet par exemple d'en utiliser un premier qui « échoue » mais tire des métriques, puis délègue au suivant qui, lui, allouera. Il parle d'une technique nommée le Tagged Allocator Store. Il suggère d'utiliser dynamic_cast pour demander à un allocateur s'il supporte ce type de service. Les allocateurs qui placent des objets en mémoire sont aussi très bons.

Q : comment ceci interagit-il avec les outils comme les Sanitizers et Valgrind? Est-ce que ça rapporte des faux-positifs?

John Lakos : c'est du logiciel comme le reste du logiciel. Si on fait un regroupement de mémoire, et si la mémoire est éventuellement remise au système (p. ex. : en bloc), faut être alertes

On en est aux préoccupations :

Les allocateurs généraux sont bons, mais généraux. On peut typiquement faire mieux. Le coût présumé d'un appel virtuel dans un allocateur PMR est souvent dévirtualisé, et les gains de localité obtenus par un allocateur local écrasent typiquement les pertes (faibles) de vitesse possibles associées à ces appels.

John Lakos poursuit avec une analogie avec les assurances (tout le monde paie un tout petit peu, mais ça rapporte beaucoup).

John Lakos se dit d'avis que le modèle moderne de passage par valeur a des coûts ppur les infrastructures. Les allocateurs mènent à des accès indirects. Il fait un certain nombre de propositions qui me semblent contre-intuitives; ça va mériter réflexion. Il trace un lien entre les regroupements d'objets et les allocateurs, mettant de l'avant que les deux ne sont pas au même niveau d'abstraction.

John Lakos dit qu'il est peut-être possible d'éliminer tous les coûts, ou du moins de les réduire au niveau des appels virtuels.

Q : est-ce que le allocator-awareness respecte l'esprit du Z0P?

John Lakos : l'esprit oui, la lettre presque

Q : à propos de la sémantique de valeur, Chandler Carruth me semble très en désaccord avec vous (John Lakos : ça arrive 😊). Y a-t-il un point milieu?

John Lakos : même avec un allocateur, on peut créer un objet. Il faut mesurer.

Q : vous semblez avoir beaucoup de données. Avez-vous des suggestions pour les systèmes embarqués?

John Lakos : on n'en fait pas beaucoup.

John Lakos a fait (sans le savoir) des tas de liens avec mon cours de la fin de semaine. J'ai vu quelques un(e)s de mes étudiant(e)s dans la salle; je me demande si elles / ils ont remarqué 😊

Je dois quitter pour le souper des étudiant(e)s...


Je dois aller au Students Dinner ce soir, pour accompagner les étudiant(e)s parmi nous et pour bavarder avec les participant(e)s aux cours de la fin de semaine. Vu que John Lakos a fini un peu plus tard que prévu (!), j'ai manqué la navette qui nous amenait à la pizzeria (souper d'étudiant(e)s oblige). Heureusement, il y en avait une autre prévue une demi-heure plus tard (finalement, ça a été plus long car il y avait du trafic dû à un accident sur la route).

Les circonstances ont fait que j'étais assis avec Bjarne Stroustrup, alors on en a profité pour jaser pédagogie, prendre une bière. J'ai pris l'occasion de le remercier, car une partie du succès de mon doctorat tient à son excellent travail (ce que j'ai fait aurait été hors de portée sans C++).

J'ai pris un peu de temps pour échanger avec JeanHeyd Meneide, qui travaille fort pour SG16 (je voulais savoir à quoi ressemblerait la consommation de mémoire de leur approche; il m'a beaucoup rassuré), et avec le papa d'April (celle qui a présenté Bjarne Stroustrup ce matin), lui-même un programmeur.

Nous avons dû partir un peu rapidement (l'autobus nous attendait) et, tristement, j'ai oublié ma tasse réutilisable de café au resto. 25CAD perdus...


Quelques remarques sur Bjarne Stroustrup. C'est quelqu'un que j'ai appris à connaître (amicalement, en surface; nous nous entendons bien mais nous ne sommes pas proches) au fil des dernières années. Il est de compagnie agréable, a accepté de faire un selfie avec un étudiant dans l'autobus (il est très généreux sur ce plan; je dois avouer le trouver très patient), et s'exprime avec beaucoup de douceur (et de fermeté, mais pas de manière agressive).

J'ai bavardé un peu avec Tony Van Eerd avant le début du panel. C'est toujours un plaisir.

Committee Fireside Chat

Jon Kalb nous accueille, et invite les gens à offrir leurs questions.

Les membres du panel se présentent. J'apprends que mon amie Hana Dusíková sera bientôt Chair d'un groupe d'études sur le Compile-Time Programming, au passage. Il y a plusieurs changements de Chairs maintenant que C++ 20 est pas mal prêt et que C++ 23 devient le focus.

Guy Davidson : quelle est la différence entre une programmeuse ou un programmeur sur le comité, et un(e) autre qui n'y est pas?

Bjarne Stroustrup : celles et ceux qui n'y sont passont plus nombreuses / nombreux.

Titus Winters : les gens hors du comité pensent que nous sommes des idiots. Pour nous, si c'est long, c'est qu'on affronte des problèmes complexes.

David Stone : il y a quand même une question d'expertise

Herb Sutter : nous vivons dans le futur. Nous travaillons sur ce que les autres pourront utiliser dans 3-5 ans.

Bryce Adelstein Lelbach : je suis d'accord. Travailler sur un projet dans le futur est perplexant pour les gens hors du comité.

Bjarne Stroustrup : nous devons toutefois rester alertes pour rester pertinent.

Q : en lisant D&E, j'ai lu que limiter le recours au préprocesseur était un objectif. Est-ce toujours le cas?

Bryce Adelstein Lelbach : on ne peut pas s'en débarrasser. Une des raisons est qu'il y a toujours une période de transition quand on introduit de nouveaux mécanismes et qu'on veut les simuler partiellement. On pourrait avoir de meilleures macros, bien sûr.

Lisa Lippincott : nous avons, il me semble, beaucoup réduit le besoin de recourir au préprocesseur au fil des ans. Le préprocesseur fait beaucoup de choses, mais ne les fait pas très bien.

Bjarne Stroustrup : les macros créent des dépendances, un peu comme les drogues. Un des problèmes de C++ est que le compilateur ne voit pas la même chose que les humains. Les templates s'améliorent, les trucs comme alignas nous aident, les modules aussi...

Vittorio Romeo : nous avons consteval pour les fonctions maintenant, et nous pourrons remplacer certaines macros avec ça. On travaille en ce sens.

Marshall Clow : dans le code que nous utilisons, il y a beaucoup de macros, entre autres pour gérer les versions de langage. On essaie de les cacher et de les localiser le plus possible.

Jon Kalb : y a-t-il des macros qui vous disparaître?

Marshall Clow : __FILE__ s'en va avec source_location

Lisa Lippincott : la réflexivité va aider

(j'ai manqué une question de Ben Deane; on a plusieurs chics réponses de métaprogrammation)

Bjarne Stroustrup : une difficulté est de faire fonctionner toutes ces jolies choses ensembles. On a des ranges maintenant, mais on ne peut pas les passer en paramètre à un constructeur.

Q : quel est votre mécanisme préféré de C++?

Marshall Clow : }

Lisa Lippincott : unique_ptr

Bryce Adelstein Lelbach : transform_reduce()

Titus Winters : les alias de types

David Stone : écrire des abstractions performantes

Hana Dusíková : méaprogrammation

Q : ce qui me fait mal en C++ est la gestion des dépendances entre bibliothèques. Que fait le comité à ce sujet? Et comment Bjarne Stroustrup enseigne-t-il ce sujet?

Bjarne Stroustrup : je ne le fais pas, mais je reconnais que c'est un véritable problème et je ne connais pas la solution.

Bryce Adelstein Lelbach : je pense que les gens sont d'avis que le comité va solutionner le problème, mais ce n'est pas possible pour un langage avec une communité aussi diverse que celle de C++

Titus Winters : certains pensent que le comité devrait imposer un Style Guide... Non! Il y a trop de domaines d'application, de besoins, de cas d'utilisation...

JF Bastien : on peut quand même aider. Les modules et la réflexivité vont quand même aider un peu.

Herb Sutter : si j'ai bien compris, tu parlais d'acquérir une bibliothèque. Il y a une grande variété de Build Systems, et nous avons des solutions.

Bryce Adelstein Lelbach : je pense qu'on doit rendre le recours aux bibliothèques tiers-partis plus facile.

Bjarne Stroustrup : nous n'aurons ni un seul ensemble de règles de style, ni un seul gestionnaire de paquetages. Il serait quand même franchement chouette s'il était simple de télécharger une bibliothèque et de l'essayer.

Q : doit-on venir de l'informatique pour faire du C++?

JF Bastien : je suis un ingénieur mécanique de formation. Ce qui fut formateur pour moi, c'est d'essayer des choses. C'est important d'explorer

Lisa Lippincott : je n'ai pas une formation d'informaticienne non plus.

Bjarne Stroustrup : j'ai une formation d'informatique et j'ai enseigné l'informatique. Le danger me semble être d'enseigner que l'informatique est simple, c'est faux, et de se limiter au bas niveau.

David Stone : il y a beaucoup à apprendre. Il y a beaucoup à contribuer. Soyez confiant, pas arrogant.

Marshall Clow : je programme en C++ depuis 1992. J'ai appris de nouvelles choses aujourd'hui.

Bjarne Stroustrup : C++ change tout le temps. J'apprends souvent de nouvelles choses.

Vittorio Romeo : pour moi, c'est faire de petits projet personnels qui a été le plus formateur.

Bjarne Stroustrup : je n'aime pas les gens qui se présentent comme plus intelligents que les autres. On ne devrait pas les laisser enseigner. On veut que les gens sortent de la classe en ayant l'impression que c'était clair.

Q : que puis-je faire pour éviter les bogues à l'exécution? (il donne son problème)

Titus Winters : utilise un Sanitizer.

David Stone : on travaille fort pour ne pas briser ton code. Si tu penses qu'on l'a fait, informe ton vendeur de compilateur et demande-lui s'il peut te fournir un avertissement.

JF Bastien : tu peux même écrire une patch pour ton compilateur à code ouvert favori!

Herb Sutter : ce n'est pas une solution qui convient à tout le monde.

Bjarne Stroustrup : il nous faut de meilleurs analyseurs statiques.

Marshall Clow : je seconde.

Bryce Adelstein Lelbach : plusieurs gens dans la communauté veulent qu'on règle leurs problèmes. Il nous faut des outils.

J'ai dû partir à 45 minutes de la fin car je commençais à craindre de manquer de temps pour me préparer pour demain matin. J'ai eu, en marchant vers ma chambre, une intéressante conversation avec un étudiant qui était d'avis que ma proposition de demain matin était une mauvaise idée. Ce fut sympathique; je pense que je vais le citer (constructivement) demain, et s'il est dans la salle, je pense qu'il va apprécier.

J'ai un peu parlé avec Za et j'ai travaillé jusqu'à épuisement, puis je me suis couché avec une présentation pas vilaine, mais pas prête...

Jour 1 17 septembre

... pour me relever vers 5 h, avec un réveil (première fois de la semaine; je me suis réveillé avant la sonnerie du réveil les jours précédents), car j'étais très fatigué. Vous trouverez un peu moins de détails que d'habitude ce matin car, après la douche, j'ai travaillé mes diapos jusqu'à la dernière minute (je suis arrivé là où je devais présenter cinq minutes avant de débuter). Je n'étais pas trop stressé avec le matériel du fait que j'ai enseigné toute la fin de semaine avec l'équipement sur place; normalement, je suis sur place beaucoup plus tôt lorsque je dois présenter.


J'ai droit à une salle à moitié pleine, ce qui est encourageant étant donné que le sujet n'est pas technique et n'intéresse sûrement pas la majorité des gens ici. Ça demeure un sujet important à mes yeux, et je suis content de pouvoir faire cette présentation.

Pour la vidéo, voir (à venir)

Pour les diapositives, voir ceci

Patrice Roy – C++ as a First Language... Really?

Brièvement, car je n'ai évidemment pas pris de notes pendant la conférence 😊

En gros, j'ai poussé un exercice que j'ai fait au Collège avec mes collègues quand j'entendais « le langage X est plus facile à apprendre / plus approprié pour des débutants que le langage Y ». Je comprends l'envie de changement, c'est humain et c'est tout à fait correct, mais je préfère quand c'est assumé (c'est cool de vouloir essayer des choses). À l'époque, vers 2016, j'avais fait l'exercice de solutionner les problèmes de première session en plusieurs langages (pseudocode, C++, C#, Java) et de regarder ce que l'étudiant(e) doit savoir pour résoudre chacun d'eux. C'était un exercice éclairant, à mon avis.

J'ai poursuivi l'effort. Entre autres, puisque plusieurs sont d'avis que Python est plus simple que les autres, j'ai fait le même exercice avec Python; si vous êtes curieuse ou curieux, ce fut un exercice enrichissant... C'est peut-être plus facile à certains égards, mais certainement moins que je ne l'aurais pensé. J'ai structuré tout ça, pour aussi en profiter pour indiquer ce qui, en C++ (car c'est le coeur de la proposition ici), pourrait rendre le langage plus agréable à utiliser avec des débutant(e)s, et dégager quelques pistes pour améliorer l'enseignement initial de la programmation dans ce langage (car je travaille sur le dossier à l'international depuis des années, et il y a clairement un problème multifacettes ici... et il me semble être humain, pas technique).

J'ai essayé de faire quelque chose d'objectif et de constructif; l'enseignement initial peut bien se faire dans tous ces langages, mais je souhaite un peu plus d'objectivité. J'espère que ce sera bien reçu.

Une note : Connor Hoekstra m'a fait remarquer que mon code d'entrée / sortie en Java est trop vieux; c'est bien possible, et je l'ai reconnu devant la caméra 😊 Je le corrigerai si je dois donner cette présentation à nouveau dans le futur (peut-être devant SG20, par exemple).

J'ai eu quelques questions, toutes intéressantes, dont une de Borislav Stanimirov qui m'a dit être totalement en désaccord avec moi 😊 Il a écrit un blogue (que j'ai lu dans le passé) sur le sujet, et souhaite entretenir un échange épistolaire sur le sujet (voir https://ibob.github.io/blog/2018/11/22/stop-teaching-cpp/ si ça vous intéresse), alors je suivrai le dossier. Ce fut courtois.

J'ai croisé Bjarne Stroustrup en marchant vers la salle de bal où se tiendra le Keynote de ce matin, et il était de bonne humeur. À titre de collation du matin, il y avait de petits gâteaux et des fruits séchés, et c'était bien bon. Je compte prendre plus d'eau que de café aujourd'hui car je suis un peu déshydraté.

Pour la vidéo, voir https://www.youtube.com/watch?v=FJJTYQYB1JQ

Pour les diapositives, voir (à venir)

Andrei Alexandrescu – "Allegro" Means Both Fast and Happy. Coincidence?

Jon Kalb et Kate Gregory prennent le plancher. Ils encouragent les gens sur place à donner leur opinion aux présentatrices et aux présentateurs, qui seront sûrement intéressé(e)s, et font le tour des informations du jour. Le premier Keynote est déjà sur YouTube (c'est fou ce qu'ils sont efficaces!).

Kate Gregory présente Andrei Alexandrescu de manière élogieuse (et méritée).

Andrei Alexandrescu commence avec un bout de code assembleur et demande aux gens s'ils savent ce que c'est. On blague un peu. Il indique aussi que Herb Sutter a un Book Signing ce midi.

Andrei Alexandrescu : quel est l'intérêt du tri? C'est le problème sur lequel il y a eu le plus de recherche dans l'histoire de l'informatique. C'est un problème fondamental. Tout(e) informaticien(ne) devait implémenter sort() une fois dans sa vie. Et si Quicksort est si populaire, c'est qu'il est simple à analyser, à programmer; qu'on peut optimiser les cas limites; que c'est rapide en moyenne – comme les ordinateurs!. qu'il fait peu ou pas de travail sur les données déjà triées (« idempotence should be cheap! »), qu'il est Cache-Friendly sur des masses de données, et qu'il est équilibré pour la charge de comparaisons et de permutations.

Andrei Alexandrescu : HeapSort a certains défauts en comparaison avec QuickSort. Il présente une implémentation naïve de QuickSort (une boucle de trois lignes, dont l'une est partition_pivot()), suivi d'un « small_sort() » pour la partir résiduelle. Il montre que le seuil à partir duquel il vaut mieux basculer vers un algorithme plus simple dépend du compilateur (pas le même pour MSVC, g++ et clang, dans quel cas ça dépend si les types sont trivialement constructibles / affectables ou pas). Pour le small_sort(), il vise un tri par insertion optimiste. Il note qu'on est bons pour les gros échantillons, bons pour les petits échantillons, et beaucoup moins bons pour les échantillons de taille moyenne. Il souhaite accroître le seuil pour basculer.

Andrei Alexandrescu procède avec une analyse de small_sort(). Regardez la vidéo parce qu'il y a des équations et je n'ai pas le temps de les formater 😊 Son pire cas est quadratique, ce qui est un peu moche, mais on parle de petits et de moyens échantillons. Il essaie un Binary Insertion Sort, et l'analyse de complexité algorithmique semble montrer que c'est un choix gagnant (réduction des comparaisons par ). En pratique, tristement, c'est une pessimisation de sur le temps d'exécution.

Andrei Alexandrescu : les recherches linéaires sont très prévisibles, ça peut expliquer la vitesse du Linear Insertion Sort. Le Binary Insertion Sort a beaucoup d'entropie (c'est un pire cas, vraiment). Moins d'opérations, plus lent. C'est la prédiction de branchements du processeur (pas la Cache) qui fait vraiment mal ici.

Andrei Alexandrescu : la recherche vise à minimiser les comparaisons; en pratique, ce qui impacte la vitesse d'exécution est l'entropie des tests. Il dit avoir essayé une tri dichotomique sans branchement... Encore pire.

Andrei Alexandrescu dit avoir ensuite essayé de réduire les permutations. Il a décidé de partir du centre et de se diriger vers les côtés (idée piquée d'un show de télé!). L'idée est de permuter moins souvent. Son middle_out_sort() est effectivement plus complexe. Il fait des manoeuvres sur les bits pour réduire les tests. Il fait remarquer que c'est pas vraiment une idée originale, et plusieurs autres y ont pensé avant lui. Cependant, malgré moins de comparaisons et moins de permutations, la différence de vitesse demeure aux alentours de , sans plus.

Andrei Alexandrescu : rendu là, les trucs intelligents n'ont pas fonctionné, alors le temps est venu... d'essayer des trucs un peu ridicules 😊 La distance moyenne des éléments à déplacer est peut-être trop grande. Essayons de la réduire. Il présente le stupid_small_sort(), qui fait make_heap() puis insertion_sort(). Plusieurs comparaisons, moins de permutations. C'est plus de travail, conceptuellement, que la version d'origine. Il utilise ensuite unguarded_insertion_sort() avec un paramètre suspect (begin+3), mais qui lui permet d'éviter de valider les bornes. Il présente la technique graphiquement. Son +3 lui donne à lui seul de gains de vitesse d'exécution. Au total, il a moins de comparaisons et moins de permutations, même s'il travaille plus. Malheureusement, à l'exécution, l'ensemble entraîne une pessimisation de sur la vitesse d'exécution.

Andrei Alexandrescu : le temps est venu de faire de la micro-optimisation. Il suggère d'aller dans la mine et de serrer la main du diable. L'algorithme pour créer un Heap est Floyd's algorithm, qu'il présente. C'est um algorithme qui travaille fort, dans une boucle... elle-même dans une boucle dû au tri. Il y a plusieurs sauts, comparaisons, permutations... Andrei Alexandrescu regarde l'implémentation de la bibliothèque standard, c'est complexe, masi plus efficace. Ils utilisent des std::move() au lieu des std::swap(), et réduisent les comparaisons, les tests et les affectations. Un des tests est pour le cas où un noeud n'a qu'un seul enfant; Andrei Alexandrescu suggère de faire comme si cet enfant n'existe pas : on le pousse sur le Heap et on fait disparaître le problème en enlevant un test de chaque itération de la boucle! Comme il nous le rappelle, il faut se battre bec et ongle pour chaque cycle d'exécution de la boucle interne. Il suggère de faire disparaître des if en introduisant les booléens dans des calculs arithmétiques.

Andrei Alexandrescu livre un plaidoyer en faveur des boucles infinies, et se permet même un goto. Si les gens ont aimé ceci, ils vont aimer ma présentation de vendredi!

Andrei Alexandrescu : malgré tout, on est proches, à du cas initial, mais pas encore meilleurs... Cependant, on peut accroître le seuil, et en accroissant le seuil, on gagne en vitesse! Ça reste de petits gains ( en termes de vitesse). Faut aller plus loin. Il trace une courbe illustrant l'accroissement du nombre de comparaison en fonction du seuil. Idem pour les mouvements. Le temps d'exécution est sa surprise : il s'améliore malgré les pessimisations! Avec plus de comparaisons, plus de mouvements, il arrive à une exécution plus rapide.

Andrei Alexandrescu : pour analyser ce qui se passe, il nous faut une métrique. Il utilise la distance moyenne entre deux accès subséquents sur un même tableau. Cette métrique est large sur QuickSort, plus petite sur un tri par insertion, et ça diminue alors que le seuil augmente. Il construit une métrique composite, qui quant à elle donne une courbe compréhensible et qui correspond aux mesures empiriques.

Andrei Alexandrescu examine ensuite le comportement en fonction de la distribution initiale des données (déjà triées, en ordre inverse, en histogrammes, permutées de un dans une direction, aléatoire, etc.). On ne peut pas spécialiser l'algorithme sur cette base. Il suggère d'optimiser le seuil en fonction des résultats sur des données aléatoires, ce qui devrait être un pire cas. Sur un tableau trié, on a le meilleur cas sur un tri par insertion, et malgré tout, son nouvel algorithme est plus rapide. La clé de la vitesse est le unguarded_... qui lui permet d'enlever des tests dans la boucle interne. Il est un peu plus rapide avec des données inversées. En histogrammes, il a perdu (il ne sait pas pourquoi). Pour les données permutées de 1 vers la gauche, c'est vraiment très mauvais... pour tous les algorithmes (QuickSort devient quadratique). Avec des données aléatoires, il gagne par plus de .

Andrei Alexandrescu : ce qu'il faut retenir : les articles scientifiques récents sont utiles (la recherche progresse), mais les livres montrent leur âge. Prenez soin de mettre en place de solides métriques, et mesurez comme des maniaques. Enfin, même si une idée semble ridicule, ça ne veut pas dire qu'elle est mauvaise.

Andrei Alexandrescu : Code that wants to be fast is left-leaning. Il faut penser comme un communiste : si votre code va vers la gauche de la page (réf. : indentation), c'est à votre avantage. Aussi, ne mêlez pas le code « chaud » et le code « froid ».

Andrei Alexandrescu : pour C++, quel serait le meilleur tri? Il offre une analyse qui dépend de la taille des types impliqués, du seuil, de la trivialité (ou pas) des mouvements et des copies, la contiguïté (ou pas) des données, et utilise des versions codées en dur pour de petites tailles. Il y a beaucoup de personnalisation; Andrei Alexandrescu pense qu'il y a une tension ici avec la programmation générique.

Andrei Alexandrescu suggère d'utiliser des annotations maison pour décrire le coût des opérations. C'est une idée avec laquelle j'ai jonglé (par voie de traits) il y a quelques années. Il mentionne qu'avec l'introspection dans C++ 23, on pourra automatiser ce genre de truc. Il pense que c'est « The Next Big Thing » 😊

Q : est-ce que ça vaut vraiment la peine de remplacer des tests par des booléens entiers?

Andrei Alexandrescu : les compilateurs sont bons, mais pas encore à ce niveau

(une question sur une subtilité de l'algorithme suit)

Q : on a des concepts et la programmation par contraintes en C++. Est-ce que ça nous rapproche de votre idéal?

Andrei Alexandrescu : je ne pense pas que c'est le bon outil. C'est difficile à utiliser pour ce qu'on essaie à faire ici.

David Hollman : j'aime l'idée des annotations définies par l'usager. On a une proposition au comité en ce sens. Suis-tu le dossier?

Andrei Alexandrescu : je pense que les annotations sont le bon outil ici. Les annotations et l'introspection vont ensemble.

John Plaice : il existe une théorie de la complexité paramétrique, qui touche à la structure des données. J'ai l'impression que ça ressemble à ce que tu proposes.

Andrei Alexandrescu : il y a pas mal de recherche dans cette zone, en effet.

(j'en ai manqué une)

Q : dans la métrique composite, il y a une constante. Que représente-t-elle?

Andrei Alexandrescu : c'est . Ça convient à la courbe.

Q : as-tu testé sur plusieurs architectures?

Andrei Alexandrescu : plusieurs machines, mais tous des processeurs Intel. Ça peut varier sur d'autres architectures.

Q : comment profiterait-on d'une connaissance statique sur le coût des copies pour mieux profiter des prédictions de branchement?

Andrei Alexandrescu : c'est un problèem difficile

Q : comment assurer la tenue à jour des annotations quand on change la structure interne de nos types?

Andrei Alexandrescu : faut une notation relative, proportionnelle au nombre d'éléments dans une structure par exemple

Q : la complexité d'un algorithme générique doit être associée à une opération

Andrei Alexandrescu : quelque chose comme ça

Étant donné que nous allons travailler sur l'heure du dîner, je suis allé me chercher un peu de bouff. En file, j'ai bavardé avec Gabriel Aubut-Lussier et Connor Hoekstra. Ce sera du riz mexicain comme hier pour moi (c'est bon, et ça remplit, au cas où je n'aurais pas le temps de souper).

Jon Kalb m'a demandé de venir en soirée à la « suite présidentielle » car il souhaite discuter avec certains d'entre nous pour le démarrage éventuel d'une CppCon Academia, soit une « track » académique pour CppCon, où l'on accueillerait des articles scientifiques ayant un lien avec le langage C++ (sur C++, utilisant C++, critiquant C++, etc.). Je vais bien sûr y aller.

Bryce Adelstein Lelbach – CppCon Program Committee

En attendant le début des travaux, j'ai une discussion intéressante (très!) avec Gabriel Aubut-Lussier sur le Epochs. Il est brillant, l'ami Gabriel. J'ai hâte devoir où il va porter cette idée.

Jon Kalb présente le plan de match, félicite Bryce Adelstein Lelbach pour son rôle de Chair, et annonce que Hana Dusíková jouera un plus grand rôle dès cette année et devenant Co-Chair.

Jon Kalb : l'appel de proposition est quelque chose qu'on essaie de faire tôt, mais la plupart des propositions nous arrivent à la dernière minute. Ça force le comité de programme à travailler de manière un peu absurde sur un court laps de temps. Il parle de techniques pour clarifier le propos quand une proposition arrive tard et qu'il y a des doutes, mais rappelle que livrer les propositions plus tôt aide vraiment beaucoup la mécanique.

Jon Kalb discute de la gestion des conflits d'intérêt. On est une relativement petite communauté, alors connaître quelqu'un n'est pas un problème en général (être le ou la partenaire de vie de quelqu'un l'est, évidemment) pour ce qui est de l'acceptation ou du refus d'une proposition.

Jon Kalb enchaîne avec l'enjeu de la manière de présenter (il réfère à Andrei Alexandrescu qui était excellent ce matin, comme toujours). C'est la raison pour laquelle avoir une vidéo et utile (il suggère de sauter par-dessus les dix premières minutes, qui sont non-représentatives, pour aller dans le coeur du propos et de la matière). Idem pour celles et ceux qui tiennent un blogue.

On enchaîne avec ce qui est propre à EazyChair, l'outil de gestion des propositions. Personne ne l'adore, mais c'est ce qu'on utilise. Jon Kalb dit utiliser C++ Now à titre de cobaye pour ses tests. Il dit être en train d'examiner un outil alternatif pour le moment, nommé Sessionize. On ne sait pas encore si on va l'utiliser dans le futur, mais c'est possible. La méthode de classement sera différente si on va là : ce serait un système de « de ces trois propositions, laquelle est la plus intéressante? » et une compilation des comparatifs sur un vaste éventail d'options permet d'établir un classement. Le problème de ce modèle est que les gens qui sont refusés ne savent pas pourquoi...

Gabriel Aubut-Lussier pense que notre système actuel ressemble un peu à une loterie; la rétroaction écrite serait idéalement constructive, mais il y a des deux types (constructives et péjoratifs), et par chance ou par malchance, certains ne reçoivent des commentaires que de l'un on l'autre des deux types. On échange sur les pour et les contre des diverses approches. Gabriel Aubut-Lussier fait remarquer qu'il serait sain de modérer les commentaires négatifs. Jon Kalb dit qu'il devrait les vérifier quand on cote quelque chose comme -2 (embarrassant), pour s'assurer que c'est justifié de manière utile. Bryce Adelstein Lelbach dit lire toutes les propositions et toutes les revues, et trancher en supplément d'un classement aveugle. Jon Kalb dit que nos chiffres (de 3 à -2) mélangent les gens, qui pensent que 3 est faible ... alors que c'est la meilleure note possible.

Une personne indique avoir soumis trois propositions, avoir reçu un oui et deux non, mais que le score de l'un des « non » était plus fort que le score de son « oui ». Jon Kalb insiste sur la question de l'équilibre des thèmes dans les présentations sélectionnées.

On a ensuite une discussion sur la gestion de propositions par des gens réputés, mais dont les propositions sont faibles ou mal préparées. C'est une discussion intéressante, mais avec du nominatif, alors je m'abstiens de la rapporter, mais disons que je penche personnellement du côté de la rigueur. C'est vraiment intéressant, et ça montre l'importance d'un comité pour éviter les dérives subjectives.

Hana Dusíková m'explique son plan de recevoir des soumissions à l'aveugle dans le futur, pour fins d'intégrité. C'est une idée intéressante. Hana Dusíková me aussi dit avoir des trucs pour des endroits pas cher lors de la rencontre à Prague (qu'elle organise) cet hiver, à distance de marche de l'hôtel. Je prends des notes, car ces rencontres peuvent être dispendieuses et marcher 15-20 minutes dans Prague pour aller travailler, c'est pas la misère.

Une fois dans la salle où Jonathan Boccara présentera, j'ai bavardé avec Jason Turner sur les variable templates et leur spécialisation, de même que sur les concepts pour contraindre les types de retour de fonctions. Je lui raconte ma mésaventure avec std::quoted() l'avant-veille de ma soutenance de thèse en 2018. On se bidonne un peu.

Pour la vidéo, voir https://www.youtube.com/watch?v=YsMUlNGF1no

Pour les diapositives, voir (à venir)

Jonathan Boccara – 10 Techniques to Understand Existing Code

Jonathan Boccara commence sans même se présenter 😊

Jonathan Boccara parle du propos de sa présentation, soit comprendre du code existant qui se présente de manière un peu hostile (du code qui ne veut pas vraiment être compris). Il compte présenter le tout sous forme de dix techniques qu'il aime tout particulièrement.

On y ira avec trois techniques pour explorer le code, quatre pour lire rapidement le code, et trois pour comprendre les petits détails.

Technique 1 : comprendre votre cadriciel d'affichage (par exemple; c'est la même chose avec la communication, les tests, la journalisation, etc.). Je vous le dit tout de suite, c'est une très bonne présentation! Pour savoir quoi chercher... (technique 2)

Technique 2 : trouver une forteresse. Se trouver un point confortable et sécuritaire à partir duquel explorer. La base de code est une carte à explorer, et la forteresse est un point d'ancrage (si petit soit-il) que l'on comprend bien. De la forteresse, on peut explorer le voisinage immédiat et étaler son territoire, ses connaissances. Il prend pour exemple une fonction d'interpolation linéaire : il y en a une dans ton code, tu trouves où ça se fait, et de là, tu peux explorer.

Une bonne forteresse permet de tisser des liens dans l'application. Par exemple, un point dont on comprend le positionnement sur la pile d'appels.

Technique 3 : analyser la pile d'appels. Une bonne pile d'appels est instructive, profonde (pour qu'on puisse en tirer plus d'affirmation par navigation), et est représentative d'un cas d'utilisation typique. Une bonne manière de trouver une pile d'appels intéressante est... un expert de la même compagnie 😊 Sinon, des utilisatrices / utilisateurs du produit. Regarder un Flame Graph peut être indicatif.

Pour la partie « lecture rapide », Jonathan Boccara prend des exemples du monde de la lecture des livres. Il suggère par exemple de ne pas lire un livre de non-fiction d'une couverture à l'autre, et suggère qu'on ne lise pas le code ligne par ligne. Aussi, le but n'est pas de tout comprendre d'un coup. Enfin, il faut se concentrer sur les endroits où l'information se trouve...

Technique 4 : commencer à lire depuis la fin. Jonathan Boccara se dit d'avis que l'information est au début et à la fin. Le début tend à être un prototype; la fin tend à être ce que produit la fonction à titre de résultat. En effet, cette variable ou ce calcul doit être au coeur du propos de la fonction... La fin peut être un retour, un paramètre modifiable, une variable membre, une entrée / sortie, la modification d'une globale, une exception...

Technique 5 : trouver les mots utilisés de manière récurrente. Il montre un monstre de COM où il y a 11 occurrences de return, 17 occurrences de value et 20 occurrences de len. Il souligne aussi des mots qui apparaissent par paires (regKey et valName dans son cas : utilisés par paires). Il met aussi en lumière que la distribution du mot dans l'espace est intructive (il a un cas de token qui apparaît plusieurs fois, mais dans un petit espace... Une fonction en devenir?).

On a des outils pour faire ce travail : nos yeux, de la coloration faite par un IDE, ou outil, etc.

Technique 6 : filtrer en fonction des structures de contrôle. En ne gardant que les lignes avec des mots comme while, for, switch, etc... le portrait qui se dégage est instructif. Jonathan Boccara mentionne la règle du 90/10. En général, plusieurs lignes ne sont pas pertinentes pour comprendre le propos. On vise la vitesse, pas la précision. On peut faire une deuxième passe au besoin. Trucs moins intéressants : variables secondaires, cas dégénérés, etc. D'un mot fréquemment rencontré, essayer de déduire un sens.

Technique 7 : chercher l'action principale. Il passe les lignes une à une pour voir la réaction des gens.

Technique 8 : découpler le code en refactorisant. Il fait un travail sur une fonction qui ressemble à ce que je fais avec mes étudiant(e)s. On peut même se débarrasser du code, mais garder le nouveau nommage.

Technique 9 : connaître les conventions. Il examine différentes signatures de fonctions et discute des sémantiques associées. On s'amuse. Il examine certains types standards, on s'amuse aussi. Évidemment, les conventions ne sont pas toujours suivies rigoureusement, alors on peut explorer aux environs pour voir ce que ça signifie.

Technique 10 : y aller par équipe. Programmation par binômes, à titre d'exemple, qui deviendrait ici de la compréhension par équipe. Avoir un regard plus neuf sur le code. Au pire, du Rubber Ducking. Être à deux aide aussi à rester concentré(e).

Je suis allé saluer rapidement l'ami Jonathan Boccara, qui est un ami épistolaire et a fait un excellent boulot, puis je suis rapidement allé dans la salle voisine pour un collège de CWG, Nathan Sidwell, qui fera un excellent travail j'en suis sûr.

Pour la vidéo, voir https://www.youtube.com/watch?v=j0CYkFPGjNg (Valentin Galea) ou https://www.youtube.com/watch?v=KVsWIEw3TTw (Nathan Sidwell, que je n'ai malheureusement pas vu)

Pour les diapositives, voir (à venir)

Nathan Sidwell – Converting to C++ 20 Modules

J'étais assis, prêt à suivre la présentation de Nathan Sidwell, quand je me suis aperçu que je vivrais un problème car mon ami, Steven Pigeon, que j'ai essayé de convaincre de venir présenter ici pendant 2-3 ans, présente tantôt... mais sa séance en est une de trente minutes, alors je devrais quitter la présentation de Nathan Sidwell en plein milieu (ce serait triste).

Je me suis donc déplacé vers la salle où Steven Pigeon présentera. Valentin Galea présentait juste avant lui (une autre présentation de trente minutes). Une idée intéressante, qu'il applique au code de Unreal, soit avoir un standard de programmation modélisé sur le standard de C++, avec des clauses nommées comme [class.def.init] par exemple, ce qui permet de faire des revues de code plus efficaces et moins subjectives.

Pour la vidéo, voir https://www.youtube.com/watch?v=Dxy66x6v4HE

Pour les diapositives, voir (à venir)

Steven Pigeon – Small is beautiful: Techniques to minimise memory footprint

Steven Pigeon prend ensuite le plancher; il a un chic chandail. Je bavarde avec René Rivera en attendant que ça ne commence. La salle est pas mal pleine, cool!

Steven Pigeon commence par la question du pourquoi (systèmes embarqués, informatique mobile, mémoire finie... Profiter au maximum de la mémoire disponible). Il met en relief que, même si on a beaucoup de mémoire, ça vaut la peine de compacter les trucs un peu pour aller plus vite.

Steven Pigeon dit qu'il va nous parler de pointeurs, de même que des enum et des « snug fit types ». Il commence en parlant des classes riches en pointeurs (p. ex. : les arbres rouge / noir), et discute de fragmentation en parlant des coûts de new et de delete, puis des vector et des Paged Lists / Paged Trees. Il présente ces dernières comme une alternative aux vecteurs, et mentionne qu'elles contiennent des pointeurs aussi.

Steven Pigeon aborde la question de la magie des pointeurs et de leur compression : l'espace logique est bien plus vaste que ce qu'on programme peut adresser directement, et que ce que le processeur peut adresser directement. Il explique que sur une machine 64 bits, nous avons plusieurs bits de disponibles par pointeur pour faire de la magie. Il base son discours sur les régions d'un programme tel que définies par le modèle de Linux. Sur les machines contemporaines, l'adresse effective où un programme est logé est déterminé à l'exécution, pour des raisons de sécurité.

Steven Pigeon décrit des pointeurs Stack-Like et des pointeurs Heap-Like. Les deux sortes de pointeurs sont très loin l'une de l'autre. Il présente la manière par laquelle glibc représent les frontières de ces zones. Il nous informe que uintptr_t est optionnel, alors il se peut qu'on doive l'inventer, et que le nombre de bits disponibles dépend de l'implémentation. Il présente un compressed_ptr<T> qui infère de manière constexpr un tas de trucs amusants. Il fait des acrobaties divertissantes pour éviter de générer des adresses nulles par accident lors de la compression et de la décompression. Il utilise des uint8_t sous la couverture pour utiliser l'alignement d'un byte. Il suggère de les cacher dans un unique_compressed_ptr<T>

Steven Pigeon parle ensuite des enum, en particulir de ceux avec un substrat choisi. Il montre des représentations à l'aide de bitfields, puis parle de l'importante d'être type-safe. Il fait un tout simple just_enough_uint<V> pour que ses choix de représentation soient plus flexibles. Il introduit une notion de fraction de bits, qui est une mesure d'efficacité de représentation (Nicolas Lawson, j'ai pesnsé à toi!).

Steven Pigeon poursuit en présentant une technique de bit-shifts fractionnels. C'est très divertissant 😊

Steven Pigeon montre comment extraire une valeur d'un champ de bit manuel, ou comment y accéder en écriture. Le snorro est arrivé à le faire à la compilation.

(il déborde du temps alloué par une minute)

Je pense qu'il s'est amusé!

Un beau bravo à l'ami Steven Pigeon qui a réussi sa rentrée. J'attendais pour lui serrer la main et Nicolas Fleury est venu me voir tout sourire; je pense qu'il a trouvé ça sympathique lui aussi.

Il y a des bouchées sur le chemin (baklavas, olives, chips de pitas, hummus); je suis content que l'on donne plus dans les légumes et le hummus l'après-midi que dans les cochonneries.

Pour la vidéo, voir https://www.youtube.com/watch?v=jozHW_B3D4U

Pour les diapositives, voir (à venir)

Anthony Williams – Concurrency in C++ 20 and Beyond

Je bavarde très brièvement avec Za, Ludo et Vayda par Skype à partir de la salle où Anthony Williams présentera. Michael Wong vient s'asseoir avec moi (j'en ai profité pour lui dire à quel point sa capacité d'organisation me fascine; il élève le concept de productivité à un autre niveau, celui-là).

Anthony Williams : C++ 20 est immense, mais certains des nouveautés touchent à la concurrence.

Anthony Williams : on a entre autres un support pour l'annulation collaborative des threads, une nouvelle classe de thread qui joint automatiquement, des nouvelles facilités de synchronisation, les coroutines, et on a raffiné les atomiques.

Anthony Williams : arrêter un fil d'exécution de force n'est pas... souhaitable. L'annulation collaborative est une nécessité. On aura std::stop_source pour demander un arrêt, et std::stop_token pour transmettre la requête. C'est tout à fait collaboratif : si le fil ne se préoccupe pas du stop_token, rien ne se produira. Ça marche un peu comme la paire promise et future : le stop_token émerge de la stop_source.

Anthony Williams : une condition_variable_any, cousine flexible d'une condition_variable, peut attendre sur un stop_token. Le wait_until() est utile ici. Il passe le stop_token par valeur; l'état sous-jacent est partagé.

Anthony Williams : il y a aussi stop_callback() pour avoir plus de contrôle, par exemple pour interrompre une entrée / sortie asynchrone.

Anthony Williams : la nouvelle classe jthread s'intègre avec stop_token pour supporter l'annulation collaborative.

Anthony Williams : sur le plan des mécanismes de synchronisation, nous avons des latch, des barrier, des counting_semaphore

Anthony Williams : le latch est un compteur à usage unique qui sert de point de rendez-vous pour plusieurs threads. Lorsque le compteur devient nul, tous les threads ayant rejoint ce point de rendez-vous sont réveillés. Il dit que c'est très utile pour préparer des tests multiprogrammés (le test démarre quand ils sont tous prêts!)

Anthony Williams : le barrier est un compteur réutilisable, et permet une synchronisation par phases (par étapes). Les threads qui arrivent à la barrier attendent qu'elle soit signalée, puis quand le compteur tombe à zéro, un des threads arrêtés va se réveiller et exécuter une fonction de complétion, après quoi le compteur va revenir à sa valeur initiale. C'est utile quand on fait plusieurs tâches, avec des parties séparées en parallèle. La fonction de complétion peut faire une réduction sur le résultat.

Anthony Williams : le semaphore (counting_semaphore<int>) est un mécanisme élémentaire qui permet de construire des mécanismes plus sophistiqués. On peut l'acquérir (acquire() et quelques déclinaisons de try_acquire...) et le relâcher (release()). Il mentionne un livre, The Little Book of Semaphores, qui montre comment tout construire avec des sémaphores... et fait apprécier le standard!

Anthony Williams : les ajustements aux atomiques incluent des mécanismes d'attente très utiles, des pointeurs intelligents et des atomic_ref.

Anthony Williams : pour les mécanismes d'attente, on a wait(), notify_one() et notify_all(). C'est comme une condition_variable de bas niveau

Anthony Williams : on a atomic<shared_ptr<T>> et atomic<weak_ptr<T>> à titre de spécialisation, même si ces deux types ne respectent pes les règles habituelles pour des atomiques. Faut faire attention, car ça peut être lent sous contention.

Anthony Williams : atomic_ref est utile au sens où ça permet de réaliser des opérations atomiques sur des objets qui ne le sont pas. Il faut que tous les points dans le code qui touchent à l'objet ainsi référé le fassent à travers une atomic_ref

Anthony Williams : enfin, les coroutines peuvent s'exécuter, se bloquer et reprendre leur exécution plus tard.

Pour le futur...

On vise une synchronisation pour des objets ordinaires (synchronized_value). Ça passera par une fonction apply(op, sv) plutôt que par un update_guard et son operator-> (c'est le même apply que std::apply(), mais spécialisé poru ce type), ce qui permet de prendre plusieurs synchronized_value d'un coup, un peu comme std::visit() peut accepter plusieurs variant.

Améliorations à std::future : continuation (then), when_all(), when_any(). Les shared_future pourront avoir plusieurs continuations

Exécuteurs (incluant les thread pools) : objet qui décide comment, quand une tâche sera exécutée.

Les coroutines auront un meilleur support pour la concurrence. On pense à task<T>.

Structures de données concurrentes : files, HashMaps

Facilités sécuritaires de réclamation de mémoire : algorithmes Lock-Free, RCU et Hazard Pointers.

Anthony Williams donne les numéros des propositions soumises au comité.

Bjarne Stroustrup : merci pour la présentation. J'ai hâte! A-t-on encore besoin de std::thread si on a std::jthread?

Anthony Williams : parfois. On peut sauver de l'espace et du temps si on est pour détacher.

Q : si je veux un async de type fire-and-forget, que devrais-je faire?

Anthony Williams : pas officiellement en C++ 20. Avec les exécuteurs, certains le permettront.

Q : est-ce qu'il y a des implémentations disponibles?

Anthony Williams : pas sur les compilateur officiels. Il y a ma bibliothèque mais je n'ai pas tout encore. Nicolai Josuttis a jthread et stop_token sur son github

Q : aura-t-on un un concurrent_priority_queue?

Anthony Williams : je ne sais pas

Q : aura-t-on des exécuteurs qui supportent l'exécution avec délai?

Anthony Williams : pas pour le moment, mais on va offrir ce qu'il faut pour les écrire

Q : est-ce qu'utiliser des atomiques entraîne une perte de performance?

Anthony Williams : en comparaison avec quoi? (il donne des exemples), Mesurez, profilez

Beau travail de l'ami Anthony Williams, compétent s'il en est un. Il a clairement mis tout son coeur là-dedans.


Comme mentionné plus haut, je suis ensuite allé à la rencontre organisée par Jon Kalb pour examiner comment nous pourrions organiser une « track » académique pour CppCon, qui serait chapeautée par IEEE ou ACM. Il y avait de la salade (miam!) et de la pizza (j'ai pris une pointe de végé parce qu'elle était piquante). Toutefois, avant, je suis passé par ma chambre pour me mettre du beaume à lèvres (déshydratation oblige). Ça m'a amené dix minutes en retard (oui, l'hôtel est grand à ce point).

CppCon Academia

Quelques trucs épars, car je ne sais pas à quel point nos deux heures de discussion sont publiques.

Nous étions une vingtaine, à l'oeil, pour la plupart des gens qui soit enseignent, soit ont organisé des colloques académiques, soit sont des formatrices ou des formateurs professionnel(le)s. Nous avons examiné la faisabilité d'une telle « track », la forme que ça pourrait prendre, ce que nous pourrions faire pour le démarrer, qui devrait prendre le tout en charge, comment ce serait intégré dans la mécanique des colloques scientifiques existants, comment nous pourrions nous démarquer, est-ce que ce serait en séquence ou concurrent avec le reste de CppCon, etc.

Ce fut intéressant, un bon échange d'idées. On n'a pas eu l'idée intelligente de nommer un(e) secrétaire (ce sera pour la prochaine fois), mais je pense qu'on voit le futur se dessiner.

Après la rencontre, Jon Kalb nous a invité à rester, mais je ne suis pas en parfaite forme et j'ai préféré retourner à ma chambre.

En soirée, j'ai échangé par écrit avec Jarryd Desmeules, bavardé un peu avec Za sur Skype, mis des documents en ligne pour mes étudiant(e)s au Collège (merci à Maxime Barakatt de m'avoir rappelé que j'avais oublié de le faire!) et je me suis couché tôt.

Jour 2 18 septembre

C'est le réveil qui m'a ramené à la conscience ce matin. Après la douche, j'ai mis mon journal de voyage à jour (j'ai été très pris depuis deux jours et c'était un peu le chaos dans mes notes), parlé avec Za, et je me suis préparé pour SG14 qui nous tiendra occupés toute la journée.

Puisque les rencontres de SG14 sont soumises au code de conduite d'ISO, il y aura moins de contenu sur le journal de voyage aujourd'hui qu'il n'y en aura pour les autres journées. On devrait normalement prendre une pause pour le Keynote de ce matin (qui recoupe les préoccupations de SG14, de toute manière).

SG14 – 8 h 30-10 h

La salle est archi-pleine et il y a des gens debout. Il fallait payer un extra pour être ici, mais nous avons décidé d'accepter les curieuses et les curieux pour fins pédagogiques (pour que les gens voient d'elles-mêmes et d'eux-mêmes quel genre de travail fait un groupe d'étude). Je serai secrétaire de la rencontre, comme à l'habitude.

Les règles ISO m'empêchent de donner le détail des travaux et des échanges de ce matin, mais une fois le volet administratif réglé (présentations, agenda, planification de la journée pour respecter les contraintes horaires des présentateurs) nous avons parlé :

Du raffinement du contrôle sur le mécanisme d'inlining des compilateurs, pour faciliter le débogage des systèmes complexes (en particulier, les jeux)

De l'interface proposée pour les mécanismes associés à l'algèbre linéaire. Ceux-ci ont pour l'essentiel été recommandés par SG14 à LEWG, mais certaines questions de design demeurent

On a un peu débordé du temps imparti. Il y a des craquelins et du fromage ce matin, avec des fruits séchés (fromage fumé, fromage bleu, cheddar). C'est très bon. J'ai bavardé avc le sympathique John Plaice, qui a assisté à la rencontre de ce matin et qui avait des questions, puis brièvement avec un collègue de la rencontre d'hier soir (il semble partager mon enthousiasme).

Pour la vidéo, voir https://youtu.be/5N4b-rU-OAA

Pour les diapositives, voir (à venir)

Ben Smith – Applied WebAssembly: Compiling and Running C++ in your Web Browser

Je croise Hana Dusíková qui est heureuse après avoir fini sa conférence (ça semble s'être bien passé, comme toujours 😊).

JF Bastien présente Ben Smith de manière élogieuse.

Ben Smith explique que JF Bastien l'a embarqué à plusieurs reprises dans diverses aventures du genre de la conférence de ce matin. Ben Smith est le Chair de WebAssembly pour C++, mais ne voulait pas venir ce matin parce qu'il a déjà les mains un peu pleines. Il travaille entre autres beaucoup sur une plus grand inclusion de groupes d'ethnicités diverses dans le monde de la programmation et chez Google, et en profite pour nous en parler.

Ben Smith relate que l'enseignement de C++ à des débutant(e)s (tiens, tiens!) fait peur à ses collègues. Il blague avec une vidéo où il utilse vim, git, etc. pour nous dire que ce n'est pas comme ça qu'on veut enseigner. Il nous présente repl.it qui est un excellent outil pour débutant(e)s. Évidemment, parfois, Internet et un obstacle et tout paralyse. Ses étudiant(e)s se font parfois des HotSpots à l'aide de leurs cellulaires pour contourner ces irritants. Pour régler ce problème, il suggère de ne pas faire un aller-retour par compilation, mais bien un aller-retour initial pour ramasser les outils de compilation, puis travailler localement, un peu comme le fait Clang in the Browser.

Ben Smith : il nous présente son plan de match, pour faire une démo, et dit qu'il expliquera comment il l'a fait, puis fera du Live Coding.

Ben Smith : pour expliquer WebAssembly, il a commencé par faire une recherche dans Internet pour définir la technologie. Il a une semi définition, mais n'est pas totalement satisfait. Il fait référence à des présentatiosn sur le sujet lors de CppCon antérieurs. WebAssembly diffère des langages d'assemblage traditionnels :

Ben Smith : que peut faire WebAssembly? En effet, JavaScript peut faire beaucoup de choses, alors on se demande... Mais WebAssembly ne fait rien en soi... à moins qu'on ne le lui permette. Un module WebAssembly a des imports (ce qu'il peut faire) et des exports (ce qu'il nous permet de lui faire). C'est à la fois une force et une faiblesse du modèle : par défaut, un module WebAssembly ne peut rien faire; en retour, si on a un module Web et un module non-Web, il se peut que l'on doive fournir aux deux des imports distincts.

Ben Smith : WASI et le WebAssembly System Interface, et se veut un standard pour compenser cette faiblesse. C'est un petit standard pour offrir un groupe minimaliste de services plus standard, plus portables.

Ben Smith : il y a aussi un outil nommé Wasm Time pour exécuter du code WebAssembly hors du Web. Pour un truc plus mature, il y a bien sûr emscripten

Ben Smith : le To-Do List est :

Il explique sa démarche (zyeutez sa vidéo ou ses diapos pour des détails). L'interface de WASI ressemble à un POSIX minimaliste. Ben Smith nous mentionne que même setjmp() et longjmp() sont supportés, et de manière horrible (il y a une danse qui passe par du code JavaScript, lève une exception, et revient... Ouf! 😊), mais ça devrait se raffiner avec le temps.

Ben Smith : le démarrage d'un programme passe par une fonction start(). Le pointeur nul correspond à l'adresse 0 est il est légal d'y accéder en écriture, mais ne le faites pas. La gestion de la pile et du tas se ressemblent, mais peuvent croître en taille selon les besoins. Ça signifie que les tableaux locaux de taille connue à l'exécution sont permis (ils utilisent une sorte de Shadow Stack pour ça).

Ben Smith : wasmtime est basé sur des capabilities, alors il faut lui donner des permissions pour qu'il puisse faire quoi que ce soit. Ben Smith nous explique que WASI n'est pas encore pleinement implémenté dans le fureteur (c'est un jeune produit), alors il a dû en faire une partie lui-même. Il contourne certaines contraintes de WebAssembly en transitant par JavaScript, où les restrictions sont moins rigides.

Ben Smith : pour produire un module WebAssembly, il faut un module (le code compilé), mais aussi une instance (le processus en exécution). On peut avoir plusieus instances par module. L'étape compile() est relativement lente, mais l'étape instantiate() est beaucoup plus rapide.

Ben Smith : exécuter un programme sur le Web demande un peu de prudence. L'interface personne machine est monoprogrammée et en JavaScript, alors il importe de ne pas la bloquer; il faut donc des Worker Threads. Il fait un fetch() pour certains modules, en garde une copie localement, et les exécute. Il utilise AceEditor, GoldenLayout et xterm.js

Ben Smith fait une démo de Live Coding avec un outil inspiré de Compiler Explorer. Un "Hello World", un exemple avec les Compile-Time Regular Expression et les dates de C++ 20 (wow!), un affichage à la console comme on en fait en première session, une fractale avec zoom, un affichage graphique avec lancer de rayon (Ray Tracing) sur canvas HTML5, un nuage brumeux en mouvement (il triche un peu avec une passe-passe croche, mais on rit), du feu à la Doom (ca prend très peu de code), une superposition de texte centré et de graphique sur un canvas HTML5 (il fait des changements et on voit l'effet en direct, c'est vraiment chouette : changement de texte, de couleur, animation, etc.). Applaudissements bien mérités! Son prototype est sur https://binji.github.io/wasm-clang/

Ben Smith aborde ensuite les limites techniques de son prototype : pas de lecture bloquantes, d'appels bloquants ou de coroutines (on peut tricher : Alon Zakai a un petit truc pour ça, apparemment, mais c'est pas idéal). Les exceptions ne sont pas supportées encore. Les threads et les atomiques non plus.

Q : les exceptions seront supportées quand?

Ben Smith : on y travaille

Q : si j'utilise du code C++ avec exceptions, ça fonctionne?

Ben Smith : oui, tant que tu n'en lèves aucune

Q : je ne vois pas comment les fonctions membres fonctionnent...

Ben Smith : il y a une structure distincte nommée table qui manipule les références qui ne sont pas des données brutes. Il y a une instruction call_indirect qui est type-safe et sert aux appels de fonctions à travers une indirection

Q : pourquoi WebAssembly est-il présenté comme 32 bits?

Ben Smith : parce qu'on pensait que ça suffirait pour commencer. C'est tout ce que nous avons pour le moment. LLVM a un target nommé wasm-64 mais je ne sais pas si ça fonctionne

Q : pourquoi ne pas utiliser emscripten?

Ben Smith : je voulais montrer comment ça marche!

Q : WebAssembly est une machine à pile. Est-ce que les types C++ sont traduits en types WebAssembly?

Ben Smith : d'une certaine manière. Ça passe par LLVM, ça devient du IR, et à partir de là on ne sait plus vraiment quel était le langage source.

Q : que se passe-t-il si on déborde d'un tableau?

Ben Smith : probablement rien (c'est pas fin), mais si tu débordes de la mémoire de l'instance, ça va trapper

(je manque une question, mais ça semblait porter sur les débogueurs pour WebAssembly)

Q : on ne peut pas modifier le code exécutable. C'est un peu par là que passe habituellement un débogueur. Comment pallier?

Ben Smith : je ne pense pas que ça va passer par là; je m'attends plus à un protocole de communication. 

C'était franchement bien, cette présentation!

Je suis allé me prendre une bouchée (des pâtes; lourd, mais ça fait le travail et c'est l'option à faible coût ici) et je suis allé voir le chic Jens Weller qui donne une présentation sur le démarrage des C++ Users Group pendant l'heure du dîner. Jonathan Boccara m'a accroché au passage pour échanger quelques mots (un individu foncièrement sympathique!); je suis bien content qu'il soit parmi nous, il est tout à fait à sa place.

Jens Weller fait des liens avec la présentation d'accueil de Jon Kalb : l'important avec C++, c'est les gens, la communauté. C'est une présentation claire et bien faite, qui trace un historique de ce mouvement et de son évolution. Il parle de diversité, d'inclusion, d'accueil des débutant(e)s et du fait que les expert(e)s peuvent aussi apprendre de ces présentations, quand bien même ce ne serait que pour parfaire leur pédagogie. Jens Weller a toujours fait beaucoup sur ce plan, c'est vraiment un leader dans le genre.

Il mentionne http://cppcom.org/ qui est un nouveau site pour accompagner les gens qui démarrent un C++ Users Group, de même que https://www.includecpp.org/ qui oeuvre à accroître le caractère inclusif et diversifié de la communauté. Bravo!

Quelques questions du public s'ensuivent. Ça dure à peu près une heure au total. On parle de commanditaires, d'éthique, de l'équilibre entre présentations pour débutant(e)s et pour expert(e)s, sur le phénomène d'attraction quand on démarre un groupe (ça fonctionne!), sur la difficulté de trouver des présentatrices et des présentateurs, sur la question de trouver des moments opportuns au calendrier, etc. Gabriel Aubut-Lussier fait valoir que le groupe de Montréal varie à la fois le jour de la semaine et le lieu pour les rencontres, ce qui permet de rencontrer de nouveaux membres; il dit avoir eu recours à la location d'une salle dans une bibliothèque au démarrage (simple, pas cher).

J'ai profité de ce moment un peu plus calme de ma semaine pour faire quelques corrections sur mes diapos du cours de la fin de semaine, et régler un bout de code qui fonctionnait mais qui était illégal (je l'avais vu en le présentant). Je vais mieux dormir ce soir.

SG14 – 14 h 5-15 h 5

J'ai croisé Margret Steele, une participante très énergique de ma classe de 2016. Elle a changé de couleur de cheveux, mais a gardé toute son énergie. J'ai essayé de la gagner à venir faire une présentation à CppCon l'an prochain. Espérons qu'elle aille de l'avant!

Les règles ISO m'empêchent de donner le détail des travaux et des échanges de ce matin, mais une fois le volet administratif réglé (présentations, agenda, planification de la journée pour respecter les contraintes horaires des présentateurs) nous avons parlé :

C'est un beau sujet, une proposition solide et bien travaillée, et nous avons eu des remarques pertinentes pour réfléchir et améliorer le design. Il y a des gens très brillants dans la salle.

Brève pause, puis on reprend les travaux.

SG14 – 15 h 20-16 h 22

Bob Steagall semble satisfait du déroulement des travaux. Je corrige les noms que j'ai mal compris à partir de la liste des présences (les gens ont été gentils, et la majorité des noms sont lisibles).

Les règles ISO m'empêchent de donner le détail des travaux et des échanges de ce matin, mais une fois le volet administratif réglé (présentations, agenda, planification de la journée pour respecter les contraintes horaires des présentateurs) nous avons parlé :

Le goûter de l'après-midi est fait de pop-corn de diverses saveurs (parmesan et truffes, chocolat, vous voyez le genre) et de carrés Rice Krispies.

Dan Saks vient s'asseoir avec moi pour bavarder (j'adore ce brillant et sage personnage). J'en profite pour le dire tout le bien que j'ai entendu de sa présentation de la veille (et c'est vrai!), où il revenait sur le mot const pour mieux le comprendre. On m'a dit que c'était un éveil pour bien des gens. En bavardant, j'ai vu des liens avec ma propre présentation de mardi, dont on a parlé, puis ça a dérivé sur celle que je compte faire vendredi. Il se trouve que Dan Saks m'a donné une piste que j'ignorais, et qu'une des idées desquelles je compte discuter est plus ancienne (de quatre ans!) que je ne le pensais. Je vais retravailler mes diapos et le remercier publiquement!

SG14 – 16 h 44-18 h

On recommence

Les règles ISO m'empêchent de donner le détail des travaux et des échanges de ce matin, mais une fois le volet administratif réglé (présentations, agenda, planification de la journée pour respecter les contraintes horaires des présentateurs) nous avons parlé :

Ouf, ce fut une journée remplie. Des présentations de qualité, des questions pointues, des débats riches en contenu. Ça valait la peine! En plus, en bavardand avec lui, j'ai appris que Mark Hoemmen était le petit fils de William Kahan, qui a inventé ce qui est devenu IEEE754. Eh ben.

Billy Baker nous a informés que des foodtrucks seraient disponibles près de l'hôtel vers l'heure du souper. Il y en avait trois : un mexicain (qui ne servait que des tacos en format tapas et des won-ton frits au fromage avec une salsa ananas et coriandre piquante; pas mauvais, un peu cher à mon goût à 20 USD la petite assiette), un grec (principalement des assiettes de gyros) et un avec des sandwiches (s'ils reviennent, j'irai là; c'était le moins cher). J'ai eu le plaisir de souper en bavardant avec Nicolas Fleury et deux de ses collègues d'Ubisoft Montréal, de même qu'avec Steven Pigeon et d'un nouvel ami anglophone dont le nom m'échappe et qui découvre l'événement cette semaine (il m'a dit avoir eu quelques présentation un peu en-dessous des attentes, mais que la majorité avaient vraiment value la peine).

Direction : les Lightning Talks. Je m'installe un peu d'avance pour mettre mon journal de voyage à jour...

Phil Nash – Lightning Talks

En attendant que ça commence, j'ai bavardé avec William Higgins, qui était dans ma classe en 2016 et qui revient régulièrement parmi nous. C'est un gars du monde du High Frequency Trading. Il m'a dit que sa compagnie avait peut-être besoin d'un formateur (ils ont plusieurs juniors talentueux). On verra; c'est un chic type, et il prépare un Lighting Talk pour ce soir, alors ça devrait être divertissant.

J'ai ensuite fait quelques ajustements à mes diapos pour tenir compte des pistes que Dan Saks m'a gracieusement offertes cet après-midi. C'est un beau cadeau!

On commence vers 20 h 30. Ben Deane, Eva Conte et Adi Shavit sont venus se joindre à moi (de la chic compagnie!).

Jens Weller : Modern C++ Macros (on rit!). Il s'amuse avec cppinsights.io et prétend qu'une partie du standard (lambdas, for, auto) sont en fait des macros spécialisées

Alexander Voronov : Language as ultimate problem solving. Il propose une approche où choisir le bon langage rend évidente la solution à un problème. Il cite Kate Gregory, puis Connor Hoekstra. Il questionne le fait qu'on pense qu'il faille un diplôme universitaire pour devenir informaticien(ne). C'est un plaidoyer pour apprendre des langages et les partager.

Gabriel Aubut-Lussier : Leaving no input unsanitized. Faut pas manquer son coup, sinon on ouvre une brèche de sécurité. Il relate une expérience d'implémentation d'une API ReST en C++. Il a fait une belle API orientée par les types avec lambda de traitement générique. C'est monadique et très joli. Bravo Gab!

Clara Macrae : Code Samples that Actually Compile. Elle a pris deux exemples de Catch2 (de Phil Nash, si je ne m'abuse! 😊) et ils ne compilaient pas. Elle a dû fouiller dans la documentation pour trouver ce qui clochait. Elle suggère une pratique pour simplifier la pratique et éviter la production de code d'exemple qui ne fonctionne pas. En générant les exemples à partir de vraies sources, elle règle essentiellement le problème. Elle utilise du Markdown pour y arriver. C'est des mdsnippets (voir mdsnippets.com).

Kris Jusiak : Postmodern Meta C++. Il fait des manoeuvres contemporaines charmantes en C++ 17 qui simulent un peu des mécanismes de C++ 20, et fait quelques acrobaties métaprogrammées.

Staffan Tjernström : Temporary Materialization. Il nous raconte une histoire de guerre... avec des xvalue. Ouf...

Manuel Bergler : Beautiful Folds. Il fait quelque chose de joli avec des paires de fonctions. Le code est incomplet, tristement, mais il a un github.

Lesley Lai : Make Impossible States Unrepresentable. Son cas d'exemple est un triplet d'optionnels, avec du code douteux.

Ezra Chung : Function Extraction with Lambda Expressions. C'est une expérience de refactorisation en introduisant une lambda et en traitant les messages d'erreur. Pas bête

Mathieu Ropert : Cato the Elder. Il veut nous parler d'histoire parce qu'il est tanné de parler de C++ 😊 C'est amusant! À la fin, qui est l'ennemi de C++? Vos propres Build Files. Il envoie un diatribe pour motiver les gens à mieux travailler.

Boris Koplackov : Why is C++ So Slow? Il veut parler de lenteur de développement. C'est une autre présentation sur la douleur des Build Tools. Il parle de ci.cppget.org

René Rivera : Algorithm Magic. Ses diapos sont une page Web. Il fait de la magie avec Sean Parent comme assistant 😊 C'est très sympathique, très réussi!

Javier Estrada : A Conversion Story: Improving from_chars and to_chars in C++ 17. Il explique ce que sont ces fonctions. Il se dit d'avis qu'il y a un pointeur de trop dans l'interface. Il déborde du temps, alors on y va par applaudissement pour savoir si on lui donne encore quelques grenailles; c'est le cas. Il nous présente son charconvutils.cpp qui se veut un simplificateur pour le code client.

Tanki Zhang : Ray Tracing in ... minutes. Il explique comment fonctionne le Ray Tracing. Il déborde du temps, alors on y va par applaudissement pour savoir si on lui donne encore quelques grenailles; c'est le cas. Le ... était 8 finalement 😊

J'ai bavardé un peu avec Adi Shavit sur le chemin du retour, et on a croisé le toujours enthousiaste Jonathan Boccara. J'aurais aimé aller prendre un verre avec Adi Shavit, mais j'avais promis à ma belle Za quelques mots doux avant son dodo, et ma belle me manque. On se reprendra pour un verre.

J'ai retourné quelques courriels, puis l'heure du dodo est venue.

Jour 3 19 septembre

Je me suis levé avec le réveil ce matin encore; j'ai pas mal de fatigue accumulée.

On m'a demandé de servir de mentor à un monsieur nommé Robert A.H. Leahy qui donnera sa première présentation cette année, et je lui ai offert mon  aide il y a quelques semaines, mais il m'a écrit hier soir pour me dire qu'il voudrait bavarder après sa présentation... malheureusement, il présentera demain après-midi, et je dois partir un peu avant la fin pour prendre mon avion (j'ai ma graduation de doctorat samedi; si je manque ça, ma famille ne me le pardonnera pas!). Je vais essayer de le rencontrer avant, et de lui donner une rétroaction plus tardive sur la base de la vidéo.

En examinant l'horaire de la cérémonie samedi, d'ailleurs, j'ai constaté qu'il sera possible de voir la cérémonie principale par le Web (l'université a un canal YouTube). On avait peu de billets (je n'en ai même pas assez pour tous mes enfants!), alors ça me soulage un peu. J'ai informé mes parents et mes beaux-parents avant de me diriger vers le premier événement de la journée.


La salle est plutôt pleine à mon arrivée.

Jon Kalb et Phil Nash – CppChat Live Episode!

Andrei Alexandrescu et Herb Sutter sont les invités ce matin.

Andrei Alexandrescu relate son cours sur le raffinement des aptitudes de présentation devant public, qu'il a donné en collaboration avec John Lakos et Kate Gregory. Herb Sutter dit y être allé et s'être fait critiquer 😊 Les deux discutent du caractère irrécupérable d'une erreur lors d'une présentation, de même que de son caractère foncièrement unique (c'est jamais la même chose, un peu comme donner un cours). Andrei Alexandrescu fait un lien avec un concert de Queen, et indique que chaque performance est distincte.

Andrei Alexandrescu ajoute qu'à son avis, après une prestation (une performance, dans ses mots), on devrait être draînés de toute énergie. Si on est relaxe, on n'a probablement changé la vie de personne.

Jon Kalb : es-tu satisfait de ta présentation cette année?

Andrei Alexandrescu : je pense que oui. La vibe de la salle était bonne. Je voulais brasser la cage un peu. Il relate les difficultés d'Alexander Stepanov pour réaliser ses idées dans d'autres langages que C++, et explique pourquoi il a voulu mettre de l'avant ce dont nous avons besoin pour programmer au XXIe siècle.

Truc amusant, Andrei Alexandrescu dit avoir reçu une rétroaction négative après avoir fait une remarque sur les Dating Apps en voulant faire une blague, et se dit désolé.

Herb Sutter : on a eu un Keynote l'an passé sur The Next Big Thing par une personne très sage (c'était Andrei Alexandrescu 😊) dans une autre conférence, et le point de la présentation était le même. Herb Sutter pense aussi que le design de langages (évolution des langages existants, conception des nouveaux langages) sera influencé par la réflexivité, en particulier la réflexivité statique. Cela influencera la frontière entre le langage et sa bibliothèque.

Herb Sutter mentionne que if constexpr, influencé par le static_if de D, est une étape sur le chemin de la réflexivité statique.

Andrei Alexandrescu : je vais brasser un peu de m... ici. Je remercie Phil Nash de m'avoir invité ce matin, mais je suis un peu trop explosif alors je préférais avoir quelqu'un de gentil comme Herb Sutter avec moi. Je ne sais pas s'il me considère son ami, cela dit...

Herb Sutter : merci de l'invitation!

Jon Kalb : de quoi parleras-tu vendredi?

Herb Sutter : ce sera une évolution de ma présentation chez ACCU sur les exceptions statiques. C'est un processus à long terme. Je vais aussi parler de RTTI, que plusieurs choisissent de ne pas utiliser, ce qui nous amène vers une communauté fracturée. Je pense qu'il faut travailler là-dessus, dans la perspective de l'évolution du langage. Je parle en mon nom ici, pas au nom du comité en entier.

Jon Kalb : je pense que chaque membre du comité est totalement indépendant et un risque sur deux pattes! >rires!<

Jon Kalb : j'aime les exceptions en général, mais c'est trop lourd pour certains cas d'utilisation, et je le comprends. C'est un choix difficile, et qui divise la communauté.

Herb Sutter : en général, le comité (incluant les éléments qui me semblaient plus résistants au changement) estime aussi que c'est un problème dont il faut s'occuper. Ce n'est pas juste parce que les gens s'en servent mal, et ce n'est pas juste parce que les implémentations ne sont pas à la hauteur. Il y a un problème d'interface, et un problème conceptuel d'implémentation. On veut quand même préserver la séparation des cas problèmes du reste du code.

Jon Kalb : dans ta proposition, on remarque que des programmeurs importants du monde ce C++ travaillent maintenant sur Swift, et travaillent sur la base de la position à l'effet que manquer de mémoire est une errur irrécupérable en général. En C++, on a toujours supposé qu'il existe des environnements avec très peu de mémoire...

Herb Sutter : dans la documentation de Swift, on indique que C++ aspire à survivre à un manque de mémoire, mais qu'eux sont d'avis que ce n'est pas possible. On constate dans plusieurs langages (Swift, mais aussi Rust, Go, C++) une mouvance à l'effet que c'est irrécupérable, mais... il y a des cas où ce l'est, et il y a des cas où c'est important. Il y a une différence entre demander un gros tampon, constater que ce n'est pas possible, puis décider de procéder moins rapidement avec un plus petit tampon (cas réaliste), et ne plus être capable d'allouer un humble int (dans quel cas ça va vraiment, vraiment mal). Go vit un problème de propagation manuelle (plutôt qu'automatique) des erreurs, et s'inspire de Swift et de ses try expressions mais avec un autre nom. Je pense que l'on va dans la même direction.

Andrei Alexandrescu : je veux revenir sur la réflexivité statique. Qui ici utilise des if? Qui préférerait ajouter deux mots et ajouter une portée? Je pense que static_if est essentiel pour l'introspection statique. On ne devrait pas essayer de remplacer if par quelque chose de plus complexe. J'ai des static_if aussi fréquemment que des if dans mon code. C'est la solution simple. Un template for, c'est compliqué pour rien. Il nous faut des blocs de base pour l'introspection. Je pense que if constexpr est une pâle copie de static_if; avec un static_if sans portée pour injecter du code, on fait un pas en avant.

Herb Sutter : je pense qu'on est d'accord pour chercher à avoir des mécanismes simples d'introspection (il y a du ping pong ici). On est violemment d'accord sur l'essentiel. On est en train de démontrer ce qui est possible dans le contexte de C++. Je suis convaincu qu'il faudra nettoyer le tout éventuellement. Je pense qu'il est un peu simple de dire que static_if et static_for sont tout ce dont nous avons besoin. Le static_if de D est consteval if... ou consteval n'importe quelle construction. C'est le même nombre de caractères!

 Jon Kalb : le temps est écoulé. La suite l'année prochaine!

Ouf, il y a eu de l'action! Tristement pour moi, quand j'ai ouvert mon ordinateur une fois dans la prochaine salle, j'ai eu un vilain plantage (un Blue Screen) et mon ordinateur a pris beaucoup, beaucoup de temps à récupérer. J'ai bavardé un peu avec Staffan Tjernström qui m'a avoué avoir utilisé quelques-uns de mes trucs pour régler un problème récemment. Tant mieux... j'imagine?

Pour la vidéo, voir https://www.youtube.com/watch?v=bIc5ZxFL198

Pour les diapositives, voir (à venir)

David Stone – Removing Metaprogramming From C++, Part 1 of N: constexpr Function Parameters

La présentation commence alors que mon ordinateur fait de son mieux pour récupérer du crash. David Stone ouvre avec un chic poème inspiré du Seigneur des anneaux. Faudrait glisser ça dans un exemple du standard.

Je n'ai pas pu noter le début, faute d'avoir un ordinateur opérationnel, mais en gros, David Stone montre ce pour quoi on peut utiliser constexpr aujourd'hui (variables, fonctions), les limites de ce mécanisme, et ce qu'il propose : permettre de passer des paramètres constexpr aux fonctions, et la surcharge qui va avec.

David Stone pense que ça va permettre d'éliminer en grande partie la métaprogrammation à l'aide de templates des usages en C++. C'est compliqué et ça fait peur. Il se dit d'avis que les programmes seront plus efficaces, et que les diagnostics seront meilleurs.

Puisque David Stone travaille sur les voitures autonomes chez Uber, il trace une analogie avec une hypothétique ville où le code de la route serait plus confus, inconséquent, changeant d'un jour à l'autre. Il parle d'un texte nommé No Shadow Worlds, où l'idée est de ne pas avoir de ghetto dans un langage, et mentionne que C++ en a au moins trois, en plus du langage de base (runtime) : les fonctions constexpr, les templates et les macros.

Selon David Stone, en C++ 11, en ne pouvant pas faire de if ou de for dans une fonction constexpr, on se trouvait dans un Shadow World très restreint. C++ 17 a enlevé beaucoup de restrictions, et C++ 20 laisse très peu de restrictions, pour faire du code constexpr du code normal.

David Stone poursuit avec les macros. Pas de boucles, de portée... C'est étrange.

David Stone présente les templates comme les ombres des fonctions, listant plusieurs limites et plusieurs contraintes du mécanisme.

David Stone liste plusieurs bibliothèques de métaprogrammation, et dit souhaiter les aider à simplifier leur modèle de programmation. Il compare accéder à un tableau par [] et accéder à un tuple par get<I>(). Il montre qu'avec sa proposition, on joindrait les deux pour obtenir le meilleur des deux mondes.

David Stone poursuit avec true_type, disant que true serait mieux, puis parle de integral_constant<T,V>, et se dit d'avis que integral_constant<int,24> devrait s'écrire 24. Il montre ensuite à quel point sa proposition simplfierait Boost::Hana. Il montre comment sa proposition simplifierait le recours à <=> aussi en éliminant certains cas pathologiques. Il montre comment simplifier les fonctions membres génériques, et comment simplifier les expressions régulières. Il montre plusieurs autres trucs que l'on veut tous faire, incluant simplifier strlen().

David Stone fait aussi valoir que sa proposition nous donne l'option de contrôler l'ordre des paramètres, ce qui peut mener à des interfaces plus claires et plus naturelles que ce que nous avons avec des templates pour le moment (bel argument). Il fait ensuite un plaidoyer sur l'importance de la syntaxe. Il liste plusieurs principes sous-jacents à sa proposition (incluant DRY), et parle (j'aime!) de respecter le temps des usagers.

La suite de la présentation de David Stone disserte sur les types pour lesquels les paramètres constexpr sont applicables. C'est raisonnable selon moi. Un cas intéressant est le cas du peut-être constexpr (pour le forwarding, en particulier), qui permet d'avoir une interface et d'utiliser if constexpr(is_constant_expression(arg)) pour prendre une décision à la compilation lorsque c'est applicable.

David Stone offre un historique du cheminement de cette proposition, ce qui est instructif pour les gens qui ne sont pas sur le comité.

David Stone parle de consteval, qui rejoint constexpr mais oblige l'évaluation à la compilation (alors que constexpr est une permission). Il montre que pour indicer un tuple, consteval serait trop strict, et constexpr traditionnel ne le serait pas assez. Il parle aussi de is_constant_evaluated() et montre que ce n'est pas exactement le niveau de granularité requis pour sa proposition, d'où is_constant_expression(arg).

David Stone mentionne les Parametric Expressions qui seraient des macros avec une portée. Cette proposition résoudrait plusieurs problèmes, et permettrait les paramètres constexpr mais créerait un autre Shadow World selon lui.

David Stone examine le nommage de « maybe constexpr », et propose un ajustement conceptuel pour réutiliser consteval.

Il finit sa présentation avec un retour sur les principes et les problèmes. C'est bien fait, bien ficelé. Bravo!

Je suis content d'être venu. J'ai eu la même idée que David Stone, à peu près en même temps (on ne doit pas être les deux seuls!), mais il a bien réfléchi à ce problème et je trouve qu'il l'a bien circonscrit.

Pour la vidéo, voir https://www.youtube.com/watch?v=ejF6qqohp3M

Pour les diapositives, voir (à venir)

Sean Parent – Better Code: Relationships

En sortant, j'ai fait des signes à Shafik Yaghmour, car s'il veut bavarder en mangeant, il ne me reste que ce midi, mais il est à l'autre bout de la salle et il y a beaucoup de gens. On se reprendra.

Le goûter du matin est des bagels, des yogourts et des fruits. Ça fait le travail. Le défaut des bagels est que ça crée un goulot d'étranglement autour des grille-pains! J'en ai profité pour prendre un bagel aux raisins (c'est bon, mais c'est le genre de truc que je perdrais à la maison car on ne les mangerait pas assez vite).

En marchant, j'ai croisé Jason Turner à qui j'ai recommandé la présentation de David Stone (c'est son genre). J'ai aussi croisé Walter Brown, qui m'a fortement recmmandé la présentation de Pete Isensee sur les destructeurs. Selon lui, c'est le genre de présentation que je devrais recommander à mes étudiant(e)s. J'en prends bonne note!

Jon Kalb fait le tour des annonces de la journée. Pour les gens qui ne vont pas au Speakers' Dinner ce soir, les foodtrucks seront de retour (ça semble avoir été apprécié). Zoe, notre autre étudiant(e) du secondaire, présente Sean Parent de manière élogieuse. Avec raison; c'est sûrement l'un des meilleurs que je connaisse.

Sean Parent : je suis impressionné de voir la croissance de ce colloque, et de voir que quelque chose que j'ai dit il y a six ans (« It's a rotate ») est devenu un meme.

Sean Parent : mes présentations dans la série Better Code ont un objectif : pas de contradictions. C'est un objectif, il est difficile à atteindre. Une contradiction dans le code, c'est un bogue. Il suit avec une citation que je paraphrase : « aux échecs, le débutant voir l'adversaire, l'amateur voir le plateau de jeu, le maître voit le jeu ». Il importe de voir les relations, et nous ne sommes pas très bons en ce sens.

Sean Parent : les relations ont une définition mathématique, une cardinalité, une modalité. Une relation implique un prédicat; si le prédicat est satisfait, la réponse est vrai. Une contrainte est une relation qui doit être satisfaite, et ce pour que d'autres relations soient satisfaites. L'implication et la contrainte sont des idées associées.

Sean Parent introduit une représentation graphique et informelle d'une relation simple, à partir d'un graphe bipartite (connecte les entités à travers une relation, et les relations à travers des entités). L'implication ajoute une directionnalité au graphe.

Sean Parent : dès que nous avons deux entités, nous avons des relations implicites. Un espace mémoire est une entité. La copie et le mouvement brisent une relation pour l'objet de destination. La destruction d'un objet brise les relations auxquelles participe cet objet.

Sean Parent : une relation de témoignage (Witnessed Relationship) est représentée par un objet. Une relation de témoignage est copiable et équality-comparable. La copie ou le mouvement brisent ou invalide le sens associé à un tel objet. Il trace un lien avec les itérateurs dans un vecteur lors d'une insertion (c'est une invalidation de la relation de témoignage). Ceci prévaut aussi pour la copie du témoin.

Sean Parent : pour cette raison, il arrive que nous bloquions la copie ou le mouvement, consciemment, pour un objet témoin (mutex, verrous, certains pointeurs intelligents).

Sean Parent : cette invalidation à distance d'un itérateur est une question préoccupante.

Sean Parent : voilà pour les pièces. Le plateau, maintenant. La structure d'un ensemble est un ensemble de relations qui lui donne du sens. Il travaille la question du sens associé à une représentation (regardez la vidéo pour ça). Une collection de bits peut modéliser une valeur, elle peut modéliser un type. Le type donne un sens aux valeurs. Dès que nous avons deux objets, nous pouvons parler de relations (comparaisons, par exemple).

Sean Parent : il existe des relations sur la base des bits plutôt que sur la base des valeurs, par exemple un hash.

Sean Parent : les objets existent dans l'espace et dans le temps. Les bits prennent une réalité physique dans une machine. Nous leur accordons un sens. Notre objet a une adresse. Les adresses peuvent être comparées. Ayant des coordonnées, les objets peuvent être ordonnancés, triés. Nous pouvons combiner les objets à l'aide d'autres opérations, par exemple l'opérateur +, pour créer de nouveaux sens (le concept de somme, par exemple).

Sean Parent : un objet qui n'a pas de sens est invalide. Un objet dans un état invalide doit retrouver un sens ou être détruit. Ceci est associé à l'idée d'un objet partiellement formé (il réfère au livre d'Alexander Stepanov). Il arrive, quand on modifie une liste, que cette liste perde son sens pendant qu'on la modifie, mais il faut que la liste reprenne son sens.

Sean Parent : une opération qui laisse un objet dans un état invalide est unsafe. Il y a une relation entre efficacité et safety. En ce sens, std::move(obj) est unsafe, laissant obj dans un état « valide mais indéfini » ce qui est une contradiction en termes. Ça ne veut pas dire que std::move() est mauvais, notez-le!

Sean Parent : avec C++ 20, deux nouvelles idées touchent la question des relations, soit les concepts et les... contrats (on rit!). Un concept est un ensemble d'axiomes satisfaits par un type. Ça remonte à An Axiomatic Basis for Computer Programming par Tony Hoare.

Sean Parent : deux objets sont égaux si et seulement si leurs valeurs correspondent à une même entité (il en dérive la symétrie, la réflexivité, la transitivité). Il montre les propriétés de la copie et de l'affectation. La copie est fondamentalement reliée à l'égalité. Par exemple, la relation < sur les entiers relatifs définit un ordre total qui est cohérent avec l'addition.

Sean Parent : les axiomes quantités ne sont généralement pas actionable. Les concepts de C++ 20 associent une sémantique avec le nom d'une opération. On fait de même en programmant. Le logiciel repose solidement sur des structures algébriques.

Sean Parent parle de Applying Design by Contracts (Bertrand Meyer, 1986). Les racines sont les mêmes que celles du texte de Tony Hoare. On parle de préconditions, de postconditions, d'invariants, et nous pouvons briser des invariants dans une méthode pour fins d'efficacité.

Sean Parent : la distinction entre concepts, applicables aux types, et contrats, applicables aux valeurs, n'est pas toujours claire. Le comparateur passé à std::sort() est-il une relation sur des valeurs ou sur des types? Une contrainte runtime pour choisir une opération est du Pattern Matching.

Sean Parent : la relation Whole-Part pour les objets composites (composition) est connectée, non-circulaire, logiquement disjointe, et décrit une possession. Les conteneurs du standard sont des objets composites, qui se comportent comme un tout et simplifient le raisonnement.

Sean Parent revient sur ses présentations précédentes, et sur la pensée simplificatrice qu'il met de l'avant. Le jeu, ici, est l'architecture. L'architecture est l'art et la pratique de la construction de structures. Il parle d'un problème concret (sauver le document à toutes les cinq minutes après les premières cinq secondes de Idle Time). Il a généralisé à « après un temps d'attente t, faire la tâche f ». Il montre le code générique et général en ce sens. Il utilise une variable globale... hum... et il manque un peu de synchronisation...

Sean Parent décrit sa pensée par un diagramme de relations, pour en faire ressortir la structure. Grâce au diagramme, le fait qu'il y a en fait deux idées, deux fonctions distinctes dans sa solution est mise en relief.

Sean Parent propose une relation On Expiration, qu'il modélise par une fonction. Son approche est pratiquement exempte de dépendances.

Sean Parent : un registre est un conteneur permettant d'ajouter un objet en retour d'une receipt (un jeton), et d'utiliser le jeton pour référer à l'objet ultérieurement (typique d'un système client / serveur). Il montre une explication... ennuyante. Il propose à la place le Russian Coat Algorithm (investiguer s'il y a un lien avec http://lafstern.org/matt/col3.pdf). Puisque les jetons déterminent une relation d'ordre, on peut retrouver un élément pas une recherche dichtomique. Aussi, le plus ancien élément inséré sera au fond du placard. Sur cette base, il remplace une unordered_map<size_t,T> par un vector<pair<size_t, optional<T>>>. Il implémente erase() en termes de lower_bound() et de remove_if(). Une démonstration suit (voir la vidéo). Les métriques de vitesse sont assassines, et l'analyse et frappante.

Sean Parent : les relations peuvent être utilisées pour fins de performance.

Sean Parent : on revient à notre objectif de ne pas avoir de contradictions. Il aborde la questions du double-entry bookkeeping, une technique pour détecter les erreurs et prévenir les fraudes. En faisant les entrées dans deux comptes disjoints, on fait une forme de validation. Il trace un historique de cette manière de travailler. C'est chouette! Si l'équation de validation n'est pas satisfaite, on a une contradiction.

Sean Parent : les tests unitaires cherchent à repérer les contradictions. Quand il y a une contradiction entre la spécification et le logiciel, c'est souvent la spécification qui est incorrecte. Quand deux relations impliquent que la même entité a deux valeurs distinctes, on a une contradiction. Une Data Race est une contradiction. On peut résoudre ce problème avec un mutex, qui est en soi une relation, mais... c'est ennuyant. C'est une patch.

Sean Parent : No Raw Synchronization Primitives. Mieux vaut penser à un plus haut niveau.

Sean Parent : en C++, déréférencer un pointeur nul est du comportement indéfini. Bien gérer les cas limites est important. Truc : utilisez des préconditions fortes pour pousser l'effort de validation vers l'appelant. On peut dire « si tu me donnes de la bouette, je vais faire de mon mieux » ou on peut dire « ne me donne pas de bouette » tout simplement.

Sean Parent : modifier une propriété peut être une relation d'écriture sur un même objet à partir de deux sources. Il examine des sémantiques possibles sur cette relation (plusieurs options : l'un des deux est redondant, le dernier va gagner, il y aura une sorte de convergence vers une valeur donnée, on écrit un dirty flag, etc.). Il se peut que ce soit tout simplement mauvais, aussi. C'est... ennuyant.

Sean Parent : No Raw Pointers. On veut raisonner localement.

Sean Parent : il faut apprendre à bien jouer le jeu. Considérer les relations essentielles. Dans un bout de code, il y a une quantité astronomique de relations à considérer; raisonner localement aide à voir la structure, à jouer un coup de manière intentionnelle, pas accidentelles. Voir se dégager la structure, l'architecture.

Q : peux-tu élaborer sur la relation entre efficacité et safety?

Sean Parent : supposons un vector<T> sur lequel je veux faire des permutations. À un moment donné, je vais sortir un objet du vecteur, et pendant ce temps il y aura un trou, un conteneur invalide, jusqu'au moment où je remplirai ce trou. J'accepte ceci pour des raisons d'efficacité; l'alternative est le recours aux copies. Les langages fonctionnels qui se veulent « puristes » mais efficaces se gardent une porte de sortie dans ces cas.

Q : les modules permettent de définir des relations entre des entités à un autre niveau. Pourquoi n'en as-tu pas parlé?

Sean Parent : bonne idée. Je vais y réfléchir, et peut-être l'ajouter à mes diapos.

J'ai beaucoup aimé, mais je pense que certains on trouvé ça trop abstrait. Je bavarde un peu avec Charles Bay et Ben Deane à propos de la présentation de David Stone ce matin; on est tous d'avis que c'est vraiment une direction intéressante.


Je me suis pris une salade (pas mauvaise, mais très petite et pour 12 USD) et un petit pain, et je suis allé faire un tour aux Lightning Talks du midi, animés par Kate Gregory.

Tianyi Zhang : hpxMP: an HPC implementation of OpenMP. Cette présentation, débutée quand je suis arrivé, portait sur une implémentation HPX de OpenMP. Ça semblait intéressant.

Michael T. Starks : (nom?). Cette présentation portait sur les tests des états privés ou protégés, et recommandait d'utiliser des classes dérivées plutôt que des amis. Si je passe un peu de temps avec l'auteur, sans vouloir le blesser, je vais lui glisser un petit mot sur le fait qu'il est totalement dans le champ 😊

Jussi Pakkanen : (nom?). Cette présentation était plus humoristique. Le présentateur recommande de remplacer tous les types par des std::string et prétend que ce sera plus simple et plus rapide. C'est drôle 😊

Ondrej Dobias : Finding String in Large Files. Il présente des algos qu'il estime plus rapides que std::search() (il travaille pour AVAST 😊). Il utilise un truc nommé asm::packed_compare_for_equal() sur 8 bytes. Il n'existe pas de std::optimal_searcher.

Mathieu Ropert : Crowd Review. Il dit vouloir faire une revue de code publique. Divertissant comme toujours. Il a pris des exemples... dans un livre... de C++... par Claude Delanoy. C'est soit horrible, soit ça ne compile pas. Oh boy... Et il montre plusieurs livres du même auteur, tous avec les mêmes exemples... Je veux pleurer... Et il finit sur un dessin de Götlib.

Ran Regev : Puzzles vs Programs. Résoudre des casse-tête, c'est un peu comme programmer. Il parle du choix des bons outils, de l'organisation du code... C'est un peu confus, mais il y a de bonnes idées et beaucoup d'efforts.

Jonathan Caves : . Dans les nouveaux trucs de Visual C++, présentés plus tôt cette semaine, un nouveau mécanisme a eu droit à une fraction de seconde. C'est ce dont je veux vous parler aujourd'hui. C'est du code C++ 20. On a quitté la Token Soup et on utilise un AST maintenant. Les Fold Expressions reposent là-dessus, entre autres. Il relate un bogue de Lifetime Extension subtil avec une λ. Il montre son expérience de débogage (le type était trop large pour... son triple écran géant!). Il montre comment il a réglé ceci et amélioré l'expérience de débogage.

Jody Hagins : Tell me Lie, Tell me Lies, Tell Me Sweet Little Lies. C++ rend le mensonge facile parfois. Il montre des incohérences entre les traits et le code client. Il pense que les concepts vont aider à écrire du code plus rigoureux.

Peter Bindels : C++ Standardization. Les gens pensent que ça arrive dans un autre espace-temps. On trouve des trucs qu'on n'aime pas. Quand ça arrive, pourquoi ne pas demander aux gens du standard pourquoi les choses sont comme elles sont? Faire une branche personnelle d'un compilateur peut être amusant... à des fins locales. Faire une branche du standard... ne donne pas grand chose. Écrivez un petit mot à quelqu'un sur le comité. Le cas échéant, écrivez une proposition. Et allez aux rencontres. Il fait un bon travail 😊

Je me prends une pomme (y a rien à faire, les meilleures pommes sont – de loin! – celles du Québec!) et je me déplace là où Lisa Lippincott, toujours brillante, présentera sous peu. J'arrive pendant qu'un groupe tient une rencontre sur le développement Web. Je profite de l'accalmie pour donner un peu de rétroaction sur des exercices à mes collègues Philippe Simard et Marc Beaulne.

Rob Irving arrive dans la salle et se couche au sol, la tête sur son sac à dos. C'est physique, une semaine comme celle-là.

Pour la vidéo, voir (à venir)

Pour les diapositives, voir (à venir)

Lisa Lippincott – The Truth of a Procedure

Lisa Lippincott, année après année, propose des conférences parmi les plus profondes et les plus intellectuellement stimulantes qui soient. Je suis certain que ce sera brillant encore aujourd'hui.

Lisa Lippincott : je me demande pourquoi on n'écrit pas de manière routinière le raisonnement formel de nos programmes pour les faire vérifier automatiquement. J'y ai réfléchi, et je pense que c'est parce que nos outils pour réaliser des preuves n'offrent pas une interface adéquate pour la programmation procédurale. Il nous faut des mathématiques avec une meilleure interface personne / machine.

Lisa Lippincott : mon champ des mathématiques est la logique. Je souhaite parler de logique procédurale.

Lisa Lippincott : la métaphore de base est Procedures are Sentences. Une procédure est un algorithme prenant forme dans lequel les événements s'inscrivent de manière temporelle et causale. Les fonctions de C++ sont des procédures en ce sens, mais pas les fonctions mathématiques. Les énoncés sont des affirmations sur le monde, qui peuvent être en accord (true) ou en désaccord (false) avec le monde. Écrire des procédures vraies permet d'éviter le comportement indéfini.

Lisa Lippincott présente un énoncé fait d'opérandes et d'opérateurs logiques, une représentation arborescente, mais préfère inverser l'arbre et présenter le tout comme un jeu à deux joueurs où chacun fait des choix. Elle fait remarquer que c'est un jeu qu'on ne peut perdre que quand c'est à notre tour de jouer. Quand le « bald guy » (qui veut true) gagne, l'énoncé est vrai. On peut inverser le sens des noeuds et faire en sorte que le « guy with the horns » (qui veut false) soit avantagé.

Lisa Lippincott présente un schème avec prologue, implémentation et épilogue où les fonctions sont telles que l'interface et l'implémentation soient séparées. Elle même son idée de deux joueurs au concept d'appel de fonction. Elle propose différentes perspectives sur une exécution d'un appel de fonction. Elle installe sa métaphore pour inclure les boucles infinies.

Lisa Lippincott introduit des claim statements, qui doivent s'avérer pour des raisons locales ou pour des raisons dans d'autres fonctions. Elle discute du concept d'être utilisable pour des variables. Elle joue sur la validation des paramètres, des préconditions comme des postconditions, les rôles de l'appelant et de l'appelé, la forme des diagrammes qui modèles les algorithmes, etc. Elle montre que, dans sa démarche, les fonctions se comporteront un peu comme des fonctions mathématiques. Le « guy with the horns » annonce les intrants, et le « bald guy » annonce les extrants. Elle fait remarquer qu'on aura true si la première pénalité va au vilain dans tous les cas, et qu'on aura false si la première pénalité va au gentil dans certais cas.

Lisa Lippincott : ce sont des jeux de Borel, sur le plan topologique (1975)

Lisa Lippincott parle ensuite ds choses nécessaires, possibles et impossibles. Elle dit que nous sommes coincés dans cette perspective. Les programmes indécidables tombent dans le « possible » puisqu'il se peut qu'ils fonctionnent. Les bonnes procédure sont dans le camp du nécssaire.

Lisa Lippincott : pour voir si notre code tient la route, on met le « guy with the horns » en charge de l'ordinateur. Il a le jeu facile, d'une certaine manière, mais il doit être conséquent. Il y a deux jeux : game of truth, game of necessity. Toute sa démarche rejoint la technique du Forcing de Paul Cohen (1963).

Lisa Lippincott : truc amusant, avec ma technique, on découvre que ma fonction de test (une factorielle) est brisée.

Lisa Lippincott : quel avantage plus fort pourrions-nous donner au vilain? Lui faire aider le gentil à écrire la fonction. C'est la game of proof. Une nouvelle règle survient : le gentil peut insérer des théorèmes. Ces théorèmes sont des fonctions, et le vilain sera éventuellement coincé à mentir, donc à perdre. C'est très profond comme truc, faudra que je le revisite en vidéo. Elle dit que c'est en fait le théorème de complétude de Gödel (1929, sa thèse de doctorat). Le problème est qu'il n'y a pas d'algorithme pour trouver les lignes à ajouter pour transformer un programme en preuve.

Lisa Lippincott montre que les problèmes ont commencé quand nous avons inséré un claim dont nous n'avions pas besoin.

Lisa Lippincott : en bout de compte, il n'y a pas de vilain, du d'en haut. Il n'y a que des gentils qui essaient de gagner.

Q : le vilain peut supposer beaucoup de choses. Entre autres, il pourrait passer une valeur arbitrairement grande...

Lisa Lippincott : l'ordinateur peut jouer le jeu de la nécessité. La boucle s'arrête parce que le vilain nous passe des valeurs vilaines, alors le truc est de faire le test quand c'est à son tour. Les juges pour ce qui est des ralentissements du jeu peuvent décider de pénaliser le vilain s'il se comporte trop mal.

Paul Hampson : comment les débordements interviennent-ils dans cet exemple?

Lisa Lippincott : l'épilogue intervient à la fin de la fonction. Il y a des règles pour l'abnormalité. La règle usable() joue un rôle.

Pablo Halpern : si le gentil gagne, qu'a-t-on prouvé vraiment? Pas que l'on a bel et bien calculé une factoriell.

Lisa Lippincott : si le gentil gagne, nous savons soit que toutes les assertions ont passé, soit que c'était au tour du vilain quand une première assertion a échoué.

David Stone : à quel point est-ce calculable de valider les affirmations dans le prologue et dans l'épilogue?

Lisa Lippincott : le fait que les juges peuvent perdre patience nous avantage.

Ouf! Fallait être en forme!

En marchant vers ma prochaine conférence, je croise Nicolas Fleury qui est allé voir les nouvelles exceptions, par Phil Nash, et se dit ravi. J'au aussi re-croisé l'ami qui était venu manger avec nous hier soir. Il semble ravi de son expérience, mais son cerveau bouille :)

Pour la vidéo, voir https://www.youtube.com/watch?v=_5weX5mx8hc

Pour les diapositives, voir (à venir)

Robert Schumacher– Don't Package Your Libraries, Write Packageable Libraries!

J'ai changé d'idée à la dernière minute (je voulais aller voir une présentation sur les Ranges), car je veux aller voir mon ami Adi Shavit et il est le deuxième d'une série de deux conférences de 30 minutes. Je suis donc allé voir Robert Schumacher de Microsoft qui discute de déploiement (un sujet important, mais moins près de moi)

Robert Schumacher donne des conseils pour que le code des biblitohèques soit plus facile à livrer et à déployer sur diverses plateformes.

Robert Schumacher : ne générez pas votre code avec -Werror ou /WX par défaut (c'est cool en développement, par contre).

Robert Schumacher : ne soyez pas hostiles au compilateur en provoquant une erreur laquo; dure raquo; si la version du compilateur ne vous sied pas.

Robert Schumacher : clarifiez votre interface : namespace, noms, ce qui est public et ce qui ne l'est pas, etc. Il nous invite à penser le code sous forme de composants, et de placer tous les fichiers à partir d'un même dossier racine.

Robert Schumacher : le Package Management est un problème dans l'espace et dans le temps. Il est plus facile de raisonner sur le design s'il y a une structure logique claire.

Robert Schumacher : ne mêlez pas le code de test et le code spécifique à telle ou telle plateforme.

Robert Schumacher : utilisez une licence claire, et placez-la dans un fichier à part entière, Incluez tout le texte, pas juste un lien. Utilisez SPDX

Robert Schumacher : soyez clairs sur le type de support que vous offrirez, dans un README. Plus ce sera détaillé, mieux ce sera

Robert Schumacher : livrez souvent. Votre Package Manager est responsable de bien le faire. Il y en a qui livrent au quotidien.

Robert Schumacher fait une petite publicité pour son produit, vcpkg 😊

Il y a quelques questions / réponses, mais je ne suis pas assez près du dossier pour en tirer profit. Une des questions porte sur les responsabilités du comité en lien avec la question du Package Management. Robert Schumacher répond bien : il y a des questions qui sont mieux traitées par des tiers partis, du moins jusqu'à ce que la meilleure solution soit connue. C'était court mais bien comme présentation.

Pour la vidéo, voir https://youtu.be/qYHDERleSL8

Pour les diapositives, voir (à venir)

Adi Shavit – Generators, Coroutines and Other Brain Unrolling Sweetness

Adi Shavit prend le plancher.

Adi Shavit : je souhaite parler de générateurs et de coroutines. Il commence avec une fonction toute simple, par exemple drawline(x0,y0,x1,y1), puis explique ce que l'on tient pour acquis à propos de cette fonction. Il fait de jolies diapos.

Adi Shavit : les fonctions sont eager et fermées, à son avis. On peut s'en sortir avec des rappels, mais ça peut devenir un petit enfer (Callback Hell). Il présente les coroutines comme une forme d'inversion de ce modèle.

Adi Shavit passe ensuite aux itérateurs, qu'il attribue à Alexander Stepanov (hum). On peut écrire nos propres itérateurs (il mentionne cv::LineIterator). Ceux-ci génèrent les éléments de manière paresseuse. Une telle génération paresseuse est ce qu'il nomme un générateur.

Adi Shavit : il y a un étrange couplage. Quand une séquence générée potentiellement infinie est-elle laquo; terminée raquo;? Il y a des conditions qui varient selon les interfaces. Un piège particulier avec une paire d'itérateurs est quand le point courant et la fin sont du même type, mais ne réfèrent pas à la même séquence. Les Ranges résolvent ce problème. Il trave un lien entre le Callback Hell susmentionné et la logique distribuée et les états centralisés qui vient avec une paire d'itérateurs lorsqu'on souhaite modéliser un générateur.

Adi Shavit : il présente donc les coroutines (fonctions résumables) comme un outil pour raisonner plus localement. Les bascules de contrôle sont coopératives, pas préemptives, et les états locaux sont des vriables locales, tout simplement. Le fait qu'une fonction soit une coroutine ou pas est un détail d'implémentation, quelque chose qui ne produit pas d'artéfact dans sa signature.

Adi Shavit enchaîne avec des exemples. Il mentionne ensuite qu'il nous manque des trucs : pour le moment, les coroutines ne peuvent retourner auto, et il n'existe pas encor de std::coro (il recommande d'utiliser cppcoro par Lewis Baker pour le moment).

Adi Shavit présente un générateur de points de couleur en spirale. C'est très joli. Il utilise une paire de de coroutines (une pour la position du point, une pour la couleur). Pour combiner les deux générateurs, il utilise un zip qui pige de l'une, pige de l'autrem et retourne une paire, et déconstruit celle-ci avec un Structured Binding. C'est du code très satisfaisant à regarder.

Adi Shavit : présente une traversée d'arbre à l'aide de coroutines. C'est aussi très joli. Le code client est d'une grande simplicité.

Adi Shavit : il reste des pièges : gestion de la durée de vie des temporaires (prenez les paramètres par valeur!), elles ne peuvent pas être constexpr, on ne peut pas les utiliser pour retourner auto ou des concepts, etc.

(l'ami Adi Shavit a fait du bon boulot!)

Je ne l'ai pas écrit encore cette semaine, mais toutes les présentatrices et tous les présentateurs que je suis allé voir ont cité leur sources, systématiquement. Ça fait du bien!

J'ai bavardé avec Mathieu Ropert en marchant. Il se dit d'avis que le standard devrait imposer des implémentations de référence et des métriques (microbenchmarks) minimales pour les implémenteurs. Je ne pense pas que ça a de bonnes probabilités de survivre au comité, mais peut-être en périphérie, qui sait?

Pour la vidéo, voir https://www.youtube.com/watch?v=oTMSgI1XjF8&feature=youtu.be

Pour les diapositives, voir (à venir)

Ben Deane – In-Place Construction: the Routine Complexities of Efficiency

Je me suis trouvé une prise de courant et je me suis assis à l'avant pour assister à la présentation de Ben Deane. Ça vaut toujours la peine...

Ben Deane : cette présentation n'est pas sur le design de types mais bien sur la construction in-place. Je pense qu'un débutant pourrait comprendre, mais que des programmeuses et des programmeurs d'expérience tendent à mal le comprendre. Il présente son plan de match. Un sondage rapide à main levée montre que la plupart des gens dans la salle sont encore sur C++ 14. Il utilise un système de petites étoiles avec un 11, un 14 ou un 17 pour identifier les diapos qui requièrent un seuil particulier de support.

Ben Deane présente un Noisy maison qu'il utilisera aujourd'hui.

Ben Deane : son premier constat est que la plupart des string sont petites, et que règle générale, déplacer une string n'est pas plus rapide que copier une string. Son microbenchmark sur QuickBench le met en relief. Il poursuit en montrant que RVO est nécessaire car le mouvement n'est pas toujours assez rapide pour nos besoins. Il ajoute que Copy Elision est une optimisation essentielle. Une illustration du fonctionnement de RVO suit.

Ben Deane : pour avoir RVO, il faut retourner soit une variable nommée sur la pile, soit une temporaire anonyme. Si on ne peut pas avoir ce bonbon, alors il faut un plan B. Il montre un cas où on retourne un paramètre passé par valeur et modifié à l'interne; ceci empêche RVO. Un autre cas survient quand on peut retourner une de plusieurs variables locales.

Ben Deane suit avec un quiz. C'est amusant. On a un cas de return (s); avec parenthèses comme le font certaines entreprises, ce qui brise l'optimisation pour certains compilateurs. Il montre ensuite ce que je montre souvent, c'est-à-dire que nommer des variables pour rien, et écrire std::move() sur une valeur de retour, c'est habituellement des pessimisations.

Ben Deane fait une pause sur la complexité des enjeux. On rit un peu. Ensuite, on se questionne sur emplace_back() et push_back(). Il met en garde les gens contre les recettes, par exemple la croyance que emplace_back() est strictement meilleur que push_back(), et tient un discours intéressant sur l'esthétique et la clarté du propos. Il se trouve que emplace_back() peut faire une construction par défaut (push_back() ne le peut pas).

Ben Deane utilise un exemple avec un vector<X> et un appel à copy() utilisant back_inserter, ce qui fait des push_back. On examine les limites, et on constate qu'il n'y a pas de back_emplacer pour le moment (note : ce serait chic avec des tuple!)

Ben Deane présente un vector<pair<K,V>> un peu comme un map<K,V> (c'est assez fréquent comme pattern), et se demande comment efficacement relayer les paramètres à un V::V d'arité supérieure à 1. Le truc est piecewise_construct et forward_as_tuple avec emplace_back().

Ben Deane : il se trouve que initializer_list a un entreposage const. Truc intéressant, ceci :

template <int ... Is> auto f() { return { Is... }; }
// ...
for(auto n : f<2,3,5,7,11>())
   // utiliser n 

... est du comportement indéfini, mais risque de fonctionner en pratique pour cette raison.

Ben Deane mentionne que string joue des tours côté vitesse (à voir sur ses diapos).

Ben Deane aborde ensuite l'initialisation d'un conteneur associatif. C'est ... compliqué. Leurs interfaces sont douloureuses. Il propose quelques fonctions d'initialisation efficaces, mis pas vraiment pour débutant(e)s. Il fait remarquer que, pour utiliser un conteneur associatif naïvement (avec les [] pour créer implicitement une valeur pour une clé donnée), il faut que le type de valeur ait un constructeur par défaut. Il se trouve qu'avec une map, emplace() n'est pas nécessairement mieux (faut l'utiliser correctement). Pour faire un emplace d'une valeur par défaut ou d'un type dont le constructeur accepte plusieurs paramètres, piecewise_construct() et forward_as_tuple sont encore une fois la chose à faire. Pour faire un emplace() de la valeur de retour d'une fonction, il suggère with_result_of (blogue d'Arthur O'Dwyer); c'est snorro!

Ben Deane : on a maintenant insert_or_assign() aussi, ce qui aide. Ben Deane fait remarquer que ça ne pourra pas appeler un constructeur explicite, alors with_result_of peut encore ici dépanner. Une critique de l'interface des conteneurs associatifs suit (et c'est mérité).

Ben Deane : les cas de optional, variant et any sont moins douloureux (ce sont des types plus contemporains).

Ben Deane nous a donné une revue instructive d'un sujet plein de pièges. Recommandable.

Q : existe-t-il des limites sur les types soumis à RVO?

Ben Deane : les temporaires, c'est Ok. Les variables nommées, c'est plus subtil.

Q : un compilateur peut-il voir à travers un copy→move→move?

Ben Deane : il n'a pas le droit. Ce n'est pas as-if.

Michael Park : l'affectation avec des variant, c'est plein de pièges. Pour le reste, avec string, il y a d'autres subtilités.

Beau boulot, cher ami!


Je vais finalement rencontrer Robert A.H. Leahy qui avant le Meet the Speakers Dinner. Un gars enthousiaste et compétent; on fait le tour de ses diapos (c'est dense, mais il n'en a qu'une trentaine). Ce n'est pas sa première présentation, et il a pris ça très au sérieux. J'avais quelques questions, et il avait des réponses crédibles. On a pris une trentaine de minutes ensemble, et je pense qu'il est prêt. Oh, et il n'y avait pas de fautes sur ses diapos (si vous me connaissez, vous savez que c'est quelque chose qui attire toujours mon attention).


Robert A.H. Leahy allait au souper lui aussi, alors nous avons marché ensemble jusque là.

Meet the Speakers Dinner

J'ai croisé Steven Pigeon en arrivant près de la salle. Lui, moi et Robert A.H. Leahy avons trouvé une table (c'était, contrairement à l'an passé, organisé de manière à ce que les gens puissent s'asseoir où elles / ils le souhaitaient, et naturellement les présentatrices et les présentateurs se sont mêlé(e)s aux gens qui payaient pour venir à leur rencontre. À notre table donc, il y avait Stefan Böhm (un des participants à mon cours de la fin de semaine, première présence à CppCon; allemand d'origine, il a donné dans la réalité virtuelle et dans la réalité augmentée en Corée pendant huit ans, et travaille maintenant à Vienne), Arvid Norberg (qui vient chaque année, mais qui ne présentait pas), Matt Mongeon (un autre qui en est à son premier CppCon et qui était dans ma classe; il donne dans ls systèmes embarqués et semble avoir passé une belle semaine... il me dit par contre que son cerveau va exploser), Meema Esguerra (qui travaille sur le comité de programme avec moi, et qui est bénévole, mais travaille pour la planification des trajets dans les voitures intelligentes pour Cruise Automation à San Francisco).

On a bavardé, le vin était bon, je n'ai pas vu d'abus malgré le nombre important de participant(e)s. Il y avait une bonne salade en entrée, du bon pain, un repas correct (j'ai eu peur quand on a mentionné poulet, haricots et patates pilées – ça sonnait un peu comme un repas de bal de finissant(e)s – mais c'était correct, bien que je l'aurais pris un peu plus chaud), un dessert pas vilain (mousse aux framboises, petit gâteau). Ils ont fait un effort avec les restrictions alimentaires : à notre table, une personne était végétarienne et une autre était intolérante au gluten (pas céliaque, heureusement), mais nous nous sommes aperçus qu'il y avait du gluten dans le dessert qui lui avait été servi.

J'ai quitté le souper vers 20 h pour aller me préparer pour la rencontre de la soirée où je devais être secrétaire. La porte était verrouillée au début (ils ont ouvert vers 20 h 20), mais j'ai eu un excellent service de l'équipe technique et je me suis préparé à temps (ça m'a simplement donné quelques minutes pour souhaiter une bonne nuit à Za en ce soir de dernier dodo sans elle).

CppCon 2020 Kick-Off Meeting

J'ai profité des quelques minutes avant que les autres membres du comité n'arrivent pour parler au photographe de l'événement. Il était partout cette semaine, mais discret et efficace. Depuis des années, notre photographe est l'extraordinaire Zoetica Ebb, une artiste multifacettes, mais elle n'était pas disponible cette fois. Le chic type qui a pris le rôle était lui aussi excellent (je ne connais pas son nom; je m'en veux un peu, mais je serai plus attentif s'il revient l'an prochain). Il me dit avoir appris quelques trucs en se promenant d'une salle à l'autre; en particulier, il dit avoir vu ce qui soulève les passions, les lignes de fracture dans la communauté, ce qui rassemble... C'est le genre de rôle qui se prête à devenir un fin observateur, je présume.

La rencontre a duré environ 90 minutes, et a été bien menéee par Bob Steagall. Puisque nous avons fait le tour de ce qui s'est bien passé comme de ce qui mériterait d'être amélioré, je vais respecter la confidentialité des échanges. Je me limiterai à dire que ce fut largement positif, et que l'événement est en bonne santé.

J'ai eu droit à des félicitations du groupe pour mon doctorat (merci!). On nous a invités à la laquo; suite présidentielle raquo; pour décompresser ensuite, mais je voulais aller faire mes derniers préparatifs étant donné que je présente tôt demain matin.


Toutefois, en marchant vers ma chambre, je suis tombé sur Gabriel Aubut-Lussier, Yuval Hager et un autre canadien de Calgary dont le nom m'échappe. Ils s'en allaient prendre une bière, et j'ai accepté d'aller en prendre une (j'ai été tellement occupé toute la semaine que j'ai souvent dû dire non, alors ça a fait du bien de prendre une petite pause). Nous sommes allés au bar de l'hôtel, ou nous avons croisé Adi Shavit (que j'ai salué, mais qui était déjà avec un autre groupe; chic type, vraiment), David Stone (que j'ai félicité pour son excellente prestation) et Samantha Luber (du moins, je pense que c'est elle; vu que je suis pas resté très longtemps, et qu'elle s'est jointe à nous peu de temps avant que je ne quitte, je n'ai pas eu beaucoup la chance de parler avec elle).

Nous sommes allés à l'extérieur. C'était frisquet, mais le paysage était beau. Je suis resté une demi-heure environ, mais j'ai dû quitter car il me restait beaucoup à faire.

Jour 4 20 septembre

Debout à 5 h du matin, comme toujours. Derniers préparatifs. C'est le départ, c'est aussi ma deuxième conférence de la semaine, alors j'ai beaucoup de préparatifs de dernière minute à faire.

Petit mot sur le contenu : il y a beaucoup, beaucoup de bon contenu aujourd'hui, et c'est triste que je doive quitter tôt. J'ai d'ailleurs parlé à Nicolas Fleury hier; il revient chez lui plus tôt lui aussi (il est nouvellement papa à nouveau, ça se comprend), mais lui aussi constate que c'est une journée particulièrement riche en contenu qu'il va manquer.

Si j'étais resté, je serais allé voir JF Bastien (Deprecating volatile), j'aurais participé au CppCon 2020 Planning Session, puis je serais allé voir Tony van Eerd (Objects vs Values: Value Oriented Programming in an Object Oriented World), Chandler Carruth et Titus Winters (What is C++), et bien sûr le Keynote de fermeture par Herb Sutter (De-fragmenting C++: Making Exceptions and RTTI More Affordable and Usable ("Simplifying C++" #6 of N)). Ça aurait été toute une journée!


Le processus de Check-Out fut fluide. Le personnel de l'hôtel a été très efficace toute la semaine durant. Les gens portent attention à nos nametags et nous adressent par notre nom; je n'ai rien eu à dire à la dame à l'accueil, elle m'a informé dès mon arrivée que tout était réglé. J'ai croisé Arvid Norberg, avec qui j'ai soupé hier soir, et j'en ai profité pour lui souhaiter un bon voyage.

Jon Kalb et Phil Nash – CppChat Live Episode!

Leur invité ce matin est Sean Parent. Nous sommes privilégié(e)s cette semaine!

Jon Kalb : parle nous de ta présentation

Sean Parent : je voulais parler de relations et de structure, à différents niveaux. Pour chacune de mes conférences, j'essaie de raconter une histoire, et d'avoir une bonne trame narrative. Quand je me prépare, une des choses que je fais est élaguer ce qui ne sert pas suffisamment le narratif.

Jon Kalb : qu'est-ce qui fut le plus difficile à couper?

Sean Parent : à la fin, je passe à travers quelques exemples de structure, mais j'avais un exemple d'une entité en relation avec elle-même (p. ex. : a += 5;), si l'entité s'échappe de sa zone du système, on risque une contradiction. Une expression comme a = min(a,b); est idempotente d'une certaine manière. Ce sont des choses importantes, mais difficiles à expliquer devant une foule.

Jon Kalb : ... mais si tu écris un livre?

Sean Parent : oui, dans un livre, ça fonctionnerait. Plusieurs me demandent d'écrire un livre. Chaque présentation que je fais est en fait un chapitre de ce livre (celle de cette semaine était le dernier chapitre du livre, au sens où j'ai donnée une conférence pour chacun des autres chapitres). J'ai un projet à livrer cette année, un cours à construire pour l'an prochain. Le livre se nommera Better Code, et il sera prêt avant ma retraite. Il y a la présentation sur les algorithmes qui n'a jamais été donnée en entier.

Jon Kalb :  Amazon A9 a plusieurs vidéos intéressantes. Veux-tu nous parler d'Alexander Stepanov?

Sean Parent : bien sûr. Photoshop était une application orientée-objet, on pensait avoir réussi, on avait nos propres exceptions construites sur setjmp() / longjmp(), c'était rapide mais c'était délicat, surtout avec les produits tiers-partis. La STL commençait à générer un buzz, et ça utilisait plus élégamment les exceptions. On passait une description d'une recherche dichotomique en entrevue d'enbauche; on a reçu un candidat un jour qui utilisait du code de la STL et... c'était beau. C'était une réponse parfaite. Je n'en ai vu que deux parfaites dans ma vie. Ce n'était pas que la recherche dichotomique : tout là-dedans est pensé avec précision et élégance. Il y a des solutions au problème de tri in situ qui était considéré un problème de recherche à l'époque.

Sean Parent : je me suis demandé laquo; mais qui écrit du code comme ça? raquo;, et j'ai été chanceux car un de mes amis travaillait chez Bell avec Alexander Stepanov. Nous l'avons invité à venir donner une conférence. Il m'a montré ce qu'il faisait, on a passé quatre heures ensemble. Il m'a dit adorer l'expérience, je lui ai dit de venir travailler avec nous. Quelques semaines plus tard, il m'a appelé et a accepté l'offre.

Sean Parent : je faisais de la recherche à l'époque. Ce fut compliqué. Il a été engagé, renvoyé et ré-engagé pour des raisons administratives. On a créé STLabs, et j'ai été le gestionnaire d'Alexander Stepanov pendant huit ans.

Jon Kalb : quand j'ai suivi des cours avec Alexander Stepanov, il m'est venu à l'idée que c'était des blocs de base pour construire...

Sean Parent : oui, il y avait même à l'origine plus d'algorithmes, et certains des laquo; oubliés raquo; font un retour aujourd'hui. C'était gros, et Bjarne Stroustrup craignait que ça ne passe pas au comité.

Jon Kalb : quand j'ai vu rotate() la première fois, je ne le comprenais pas. Puis, j'ai compris que c'est un bloc pour construire d'autres algorithmes.

Sean Parent : oui. C'est un algorithme intéressant, car il permet d'exprimer une vaste quantité d'autres idées plus complexes.

Jon Kalb : que fait la candidate ou le candidat moyen avec la question de la recherche dichotomique?

Sean Parent : la plupart livrent quelque chose de correct en temps logarithmique, imparfait mais pas mal, mais ont de la difficulté à expliquer ce que cela fait. Une erreur typique est de faire une recherche dichotomique jusqu'à ce qu'un élément égal soit trouvé, puis suivent avec une recherche linéaire. Certains algorithmes n'expriment pas clairement leurs préconditions. Évidemment, certains invididus répondent de manière inappropriée aux critiques. Par exemple, laquo; c'est une bonne réponse, mais ce passage est inefficace; comment peut-on l'améliorer? raquo;. Nous avons parfois des réponses spectaculairement mauvaises. Nous avons parfois des réponses qui viennent avec un jeu d'essai complexe, mais supposent que tous les éléments dérivent d'une classe Searchable qui n'était pas dans l'énoncé. Certains nous offrent une dissertation sur la beauté du modèle objet, mais ne parlent pas du tout de l'algorithme...

Jon Kalb relate une expérience personnelle où il devait travailler avec une masse de données. On lui avait recommandé d'utiliser la STL. Il compare avec une solution maison faite avec de bonnes intentions, mais qui mêlait le tout avec une recherche linéaire...

Sean Parent : j'ai travaillé chez Apple sur une transition d'un émulateur. Il y avait un mélange de vieux code et de nouveau code. C'était non-trivial, et nous n'avions pas le véritable matériel. On souhaitait démarrer le système d'exploitation, nous tracions le code avec un analyseur logique, et Apple devait nous livrer un débogueur mais ça prenait du temps. On a mis de la pression pour savoir ce qui se passait. Ils avaient une solution orientée objet avec une classe TOpCode, mais... nous voulions démarrer la machine! Nous avons pris les sources et nous avons résolu le problème. Les solutions over-engineered ne sont pas toujours à propos

Jon Kalb : j'ai compris qu'Alexander Stepanov n'était pas un fan de la programmation orientée-objet...

Sean Parent relate une histoire avec le Tea Pot classique qu'on voit souvent dans les démos graphiques. Il dit que Alexander Stepanov ne travaillait pas vraiment sur Photoshop. Je lui expliquais un problème à résoudre, il m'a arrêté après quelques étapes : tu te trompes. Quoi? Mais... Il est allé au tableau, a pris mes énoncés, pouf! Contradiction. Je lui ai demandé quelle était la bonne réponse. Sa réponse : je ne sais pas, c'est ton problème >rires!<

Sean Parent : c'est important de travailler avec des gens plus intelligents que soi. C'est enrichissant.

Jon Kalb : comment ton travail sur Photoshop, avec la STL, a-t-il amené l'évolution de ce programme?

Sean Parent : le programme était originalement écrit dans un Framerwork en Object Pascal. Éventuellement, on a migré vers une implémentation locale de C++. Ça restait fortement orienté-objet. Le passage au code générique a fonctionné car c'est un modèle inclusif, alors que les modèles orientés-objets tendent à exclure les autres approches. On a pu migrer et intégrer le vieux code. L'équipe a grandi, c'est un défi, et les aptitudes sont variées. Quand on a migré Photoshop sur le iPad, on a pris le code, ça a fonctionné du premier coup, et on pouvait ouvrir une image d'un gigabyte avec seulement 40Mo de mémoire.

(je dois partir avant la fin car ma présentation approche)...

C'était intéressant tout ça...

Pour la vidéo, voir https://www.youtube.com/watch?v=KNqRjzSlUVo

Pour les diapositives, voir ceci

Patrice Roy – Some Programming Myths Revisited

Je me suis ensuite dirigé vers la salle où je devais présenter.

Je dirais que la salle était pleine aux trois quarts environ, peut-être un peu plus. Avec les questions, je m'en suis sorti à 58 minutes sur les 60 disponibles. J'ai eu des réactions, des rires, des questions (et des commentaires) pendant la présentation, mais c'était matière à controverse et je m'y attendais.

J'ai aussi eu des questions riches et pertinentes de gens comme Peter Sommerlad, qui faisait remarquer que même MISRA en était venu à la conclusion que plusieurs return dans une fonction ne nous plaçait pas violation du principe de point de sortie unique, et Andrzej Krzemieński qui faisait remarquer (à juste titre!) qu'initialiser les variables de manière automatique tendait à masquer les bogues, qui échappent alors aux analyseurs statiques. Ça s'est, ma foi, très bien passé.

J'ai bavardé avec Matt Mongeon en me dirigeant vers l'endroit où j'avais laissé mes bagages. Ne restait plus qu'à appeler le taxi, attendre un peu, et filer vers l'aéroport


Valid XHTML 1.0 Transitional

CSS Valide !