À propos de cppcon 2019

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

Début du contenu technique

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

Fin du contenu technique

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++ :

• Système de types statique extensible aux types des usagers
• Sémantique de valeur et sémantique de référence
• Même support pour les types fondamentaux et pour les types des usagers
• Support direct du matériel et du système d'exploitation
• Gestion systématique des ressources (RAII)
• Supporter la composition de composants logiciels développés séparément
• Supporter la programmaton orientée objet
• Supporter la programmation générique
• Supporter la programmation dès la compilation
• Utilisation directe des ressources systèmes
• (il y en avait une dizaine, chacune a été expliquée sommairement).

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.

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é)

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) :

• Un crash de Tesla sur un camion à ordures arrêté sur le bord du chemin. Le système de freinage demandait l'agrément de la caméra et du radar, et l'un des deux ne détectait pas l'obstacle
• Un crash de Tesla qui a embouti un camion qui tournait à gauche... car il était blanc, comme le ciel ce jour-là
• Un crash de Tesla qui a embouti un pickup stationnaire... en accélérant vers le camion... parce que le camion a changé de voie alors que la Tesla estimait une grande distance entre le véhicule et celui qui le précédait
• Un crash de Uber (avec individu à l'intérieur en backup). À six secondes de l'impact, un système de détection de distraction du conducteur a été éteint, un on a frappé un cycliste

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.

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 :

• Une macro définie dans une unité de traduction d'un module reste dans le module
• Une macro définie dans une interface de module y reste aussi
• Quand on utilise une unité d'en-tête, les macros s'échappent

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 :

• inclusions (s'il y en a)
• déclaration de module
• déclarations import
• déclarations export (s'il y en a)
• déclarations partagées avec le reste du module
• ...
• partition privée (s'il y en a, et si nous sommes dans l'interface du module)

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 XXI^e 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.

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 classiques n'étaient pas à la hauteur (il les considérait inutiles)
• Les allocateurs de C++ 11 sont douloureux
• Les allocateurs de C++ 17 sont bien meilleurs
• Les gens s'inventent des raisons (fausses!) pour ne pas aimer les allocateurs (John Lakos en liste quelques-unes, et se permet une charge contre la sémantique de mouvement)

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.

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.

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).

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 $15\%$). En pratique, tristement, c'est une pessimisation de $13\%$ 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 $1\%$, 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 $3\%$ de gains de vitesse d'exécution. Au total, il a $9\%$ moins de comparaisons et $20\%$ moins de permutations, même s'il travaille plus. Malheureusement, à l'exécution, l'ensemble entraîne une pessimisation de $9\%$ 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, à $2\%$ 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 ($3\%$ 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 $46\%$ plus de comparaisons, $88\%$ plus de mouvements, il arrive à une exécution $4\%$ 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 $9\%$ 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 $3\%$.

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 $\frac{1}{500}$. Ç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

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.

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).

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é!

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

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.

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

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 :

• C'est un machine à pile fortement typée
• ... mais elle a une quantité infinie de registres (il donne des exemples, quelques instructions, une fonction... Le comportement de base est effectivement une pile, et la valeur de retour d'une fonction est le dessus de la pile)
• WebAssembly est validé avant exécution (puisque le fureteur ne peut être mis à risque). Validation des types, validation des bornes...
• WebAssembly est muni d'une spécification vérifiée formellement et mécaniquement (Ben Smith nous indique quelques articles scientifiques sur le sujet)
• WebAssembly est un standard du W3C
• WebAssembly est une architecture Harvard : le code et les états sont séparés, ce qui empêche les programmes auto-modifiants ou qui corrompent la pile des appels. Cela réduit les risques de certains types d'attaques
• WebAssembly n'a pas de branchements non structurés (pas de goto), et se limite aux structures de contrôle que Dijkstra aurait aimé
• Il est possible de générer du code WebAssembly à travers Compiler Explorer (il donne un exemple)

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 :

• Obtenir un SDK de WASI
• Compiler Clang
• Compiler LLD

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. 

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).

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é :

• De la proposition de bibliothèque d'algèbre linéaire

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.

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 contrôle sur la disposition des variables membres d'un objet
• De ce que devrait contenir une bibliothèque Freestanding, pour les systèmes aux ressources limitées (nous avons dû prendre la pause avant d'avoir traité ce dossier)

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é :

• De ce que devrait contenir une bibliothèque Freestanding, pour les systèmes aux ressources limitées (suite et fin pour aujourd'hui)
• De découverte de topologie des ressources d'un système et d'affinité des ressources

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 😊

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 XXI^e 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!

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!

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.

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 😊

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.

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 😊

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!)

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.

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)...

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é.