À propos de cppcon 2017

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.

Glossaire

Quelques termes que vous verrez ci-dessous :

• Core : le groupe de travail de WG21 qui travaille sur la précision du texte du standard.
• CTP : Community Technical Preview, une mise à jour partielle de compilateur, souvent gratuite
• EWG : l'Evolution Working Group, dont s'occupe présentement Ville Voutilainen
• LEWG : le Library Evolution Working Group, dont s'occupe présentement Jeffrey Yasskin
• LWG : le Library Working Group, dont s'occupe présentement Marshall Clow
• SG12 : le groupe d'étude sur le comportement indéfini dont je fais partie
• SG14 : le groupe d'étude sur les systèmes à basse latence (monde de la finance, systèmes embarqués, jeu vidéo) dont je fais partie
• WG21 : comité de standardisation de C++

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

Ceci fera peut-être sourire certains de mes collègues et de mes étudiants, car il est d'usage d'utiliser C# comme langage de script dans Unity, mais il se trouve que si le moteur Unity lui-même était exécuté par le Cadriciel .NET, ce serait beaucoup trop lent, et ce serait illégal sur plusieurs plateformes comme la PlayStation 4 ou iOS qui ne permettent pas à un programme de se modifier à l'exécution comme le font les machines virtuelles Java ou .NET. Ce que l'équipe de Unity fait est de transformer le code IL de .NET en code C++ pour utiliser les compilateurs C++ sur les plateformes visées et générer du code plus efficace.

Learning and teaching C++

Bjarne Stroustrup commence en se disant honoré d'avoir reçu ce prix. Il dit vouloir parler de quelque chose d'important pour toutes et tous dans la salle, mais qui n'a pas été discuté en plénière à CppCon par le passé.

Bjarne Stroustrup cite George Bernard Shaw, une jolie citation qui se termine par « ...therefore, all progress rests on the shoulders of unreasonable men ».

Bjarne Stroustrup : nous enseignons tous, mais à qui? Comment? Et nous sommes tous étudiants, avec le devoir de se mettre à jour dans un monde qui bouge rapidement. Prendre du retard signifie faire partie du problème.

Bjarne Stroustrup : pour nous, qu'est-ce que le C++ moderne? Que souhaitons-nous que les participant(e)s tirent d'une de nos « unités d'enseignement »?

Bjarne Stroustrup : à qui enseignons-nous? Les étudiant(e)s débutant(e)s ou gradué(e)s ont leur bagage et leurs attentes; les professionnel(le)s ont un vécu différent, d'autres attentes, teintées entre autres par leur expérience de programmation avec d'autres langages (incluant C++ 98); les professionnel(le)s sans expérience de programmation sont un autre groupe, avec des attentes et des particularités différentes.

Bjarne Stroustrup : connaissez vos étudiant(e)s.

Bjarne Stroustrup : nous avons fait un très mauvais boulot pour enseigner C++ avant 1998. C++ n'a jamais été pensé pour être un nouveau C, ou un quasi Java, ou encore un ramassis de particularités disjointes. « certains » ont en quelque sorte piraté le message, et on rempli des espaces avec des philosophies inappropriées pour ce langage.

Bjarne Stroustrup présente ensuite son vécu d'enseignant, et rappelle qu'il enseigne encore aujourd'hui. Il a beaucoup enseigné à des Freshmen (débutant(e)s au baccalauréat), et bien sûr à des étudiant(e)s gradué(e)s plus avancé(e)s. Il a aussi écrit quelques livres (il en présente trois, qui proposent des introductions à C++ mais avec des objectifs et des perspectives qui diffèrent de l'un à l'autre). Il suggère de démarrer la rédaction avec un but clair.

Bjarne Stroustrup relate la réaction des gens de l'industrie au sujet dont il souhaite parler aujourd'hui. Souvent positive. Il relate aussi la réaction des enseignant(e)s, plus craintifs devant l'envergure de la tâche. Selon lui, enseigner est un problème pratique à la fois difficile et important, qui implique enseigner à la fois des principes fondamentaux et des habiletés pratiques.

Bjarne Stroustrup : il y a plusieurs manières d'utiliser (et d'enseigner) C++, le langage et son usage en termes de praxis. Un(e) enseignant(e) doit faire des choix, et articuler ses objectifs. Les étudiant(e)s pour leur part vont faire des choix, et ne retiendront pas tout ce que nous leur aurons proposé.

Bjarne Stroustrup abord ensuite une série d'objectifs d'enseignement possibles. Intéresser à la programmation (en particulier pour des débutant(e)s); attirer plus d'étudiant(e)s en classe; enseigner l'écriture de programmes simples... Il dit s'intéresser plus à la mise en place des fondations pour une carrière féconde et intéressante, incluant la pratique de la programmation, et dit avoir moins d'intérêt pour un enseignement qui prendrait la programmation comme un simple outil. Bjarne Stroustrup critique plusieurs manuels de C++, qui manquent de focus et s'intéressent surtout à la syntaxe (surtout de la syntaxe de 1998).

Bjarne Stroustrup : enseigner la programmation ne se limite pas à des particularités de langages, à des règles de conversion arithméiques. Il ne vaut pas la peine d'essayer de tout enseigner (il y en a trop!). Bjarne Stroustrup suggère de choisir des sous-ensembles cohérents, et de mettre l'accent sur des bibliothèques de grande qualité. Essayer d'écrire une meilleure liste chaînée que std::list est un exemple de focus mal placé.

Bjarne Stroustrup recommande d'éviter d'être trop astucieux. Il ne sert à rien de montrer des concepts et des mécanismes avancés lorsque les bases ne sont pas en place. Il faut prendre soin d'expliquer les raisons derrière ce que nous présentons. Nous voulons que les bonnes idées et les bonnes techniques prennent racine dans la tête de nos étudiant(e)s; nous ne voulons pas avoir l'air intelligent(e)s. Mieux vaut enseigner une solution simple qui sera comprise qu'une solution obscure. Laissons l'égo hors de la classe.

Bjarne Stroustrup recommande d'avoir recours à des outils : en plus des manuels et des exercices, utiliser un IDE, on débogueur, un outil de gestion des sources, un profileur... et de grâce, des outils à jour! Il prend soin d'ajouter que se limiter à des programmes console donne une impression de langage inintéressant, alors que le monde graphique tout entier repose sur des applications C++ graphiques. Il recommande d'utiliser des bibliothèques pour accéder au Web, à des BD.

Bjarne Stroustrup : enseigner la programmation implique enseigner des principes et de la praxis. Se « mettre les mains dedans », en quelque sorte. Ce n'est pas facile, ce n'est pas rapide, mais il faut faire quelque chose.

Bjarne Stroustrup : la complexité s'oppose à l'enseignement. Ne faites pas croire à la magie, toutefois; un cours est une fondation pour apprendre plus, pas une fin en soi. Programmer repose sur de multiples strates d'abstraction, et il est sain de comprendre comment ce que nous faisons communique avec les strates les plus proches.

Bjarne Stroustrup : visez à inspirer les étudiant(e)s, pas à les décourager. Programmer peut être une expérience transformative (ce le fut pour plusieurs personnes dans la salle).

Bjarne Stroustrup dit que nous avons un devoir de succès. Nous formons les futures générations de programmeuses et de programmeurs. Offrons-leur un langage riche, pas un langage appauvri, et évitons les monocultures : C++ n'est pas le seul langage pertinent. Amenons une saine dose d'idéalisme, faisons mieux, apprenons de nos erreurs.

Bjarne Stroustrup trace une analogie entre la photographie et l'enseignement de la programmation, en montrant comment divers segments de l'industrie desservent diverses catégories d'individus. Il parle de l'importance de la qualité de l'équipement, des actes posés par les usagers, des variations en ce qui a trait à la patience, aux habiletés, aux efforts investis, aux goûts individuels. Les besoins des usagers varient, et il en va de même pour ce qui est de leur tolérance à l'erreur. Il présente diverses qualités d'appareils photo, d'ajouts possibles à ces appareils, et va du très haut calibre (professionnel) aux appareils « grand public » qui viennent souvent complets en soi.

Bjarne Stroustrup décrit ensuite le déploiement de l'empaquetage des appareils photos, et trace un parallèle avec ce que nous vivons dans le monde de C++. Nous avons besoin d'une sorte de système pour mieux distribuer et publiciser nos bibliothèques (je suis tellement d'accord avec lui là-dessus!). Il suggère divers niveaux de distribution, allant du simple (essentiellement, on le télécharge, on clique, ça fonctionne) au professionnels (fortement paramétrable). Il n'y a pas de solution unique ici, qui conviendrait à toutes et à tous.

Bjarne Stroustrup se dit d'avis que les modules aideront. Il donne un exemple concret, indiquant que différentes interfaces pourront donner différents niveaux de complexité et de contrôle. Il se dit heureux des progrès dans les outils de déploiement, mais ces outils demeurent trop difficiles d'approche pour les étudiant(e)s et pour la communauté en général. La paire « download X; install X » et l'équivalent à ses yeux de import X avec un module.

Bjarne Stroustrup rappelle qu'il n'existe pas de Value-Neutral Teaching. Nous faisons des choix en enseignant, indiquant ce qui est bon et ce qui l'est moins. Nous enseignons de manière moderne ou pas. Le C++ moderne est selon-lui Type-Safe de manière statique, Resource-Safe (RAII), permet les abstractions à coût zéro, l'encapsulation et le respect des invariants, etc. Le C++ moderne n'est pas Java, C# ou C++ 98; l'inertie est antagoniste à la bonne programmation. Ce qui était bon il y a vingt ans peut ne plus l'être aujourd'hui.Bjarne Stroustrup mentionne aussi que plusieurs étudiant(e)s aujourd'hui pensent en savoir plus que l'enseignant(e), ou préfèrent le Web à leur enseignant(e), ce qui fait partie de ce qu'un(e) enseignant(e) doit tenir compte dans sa pratique.

Bjarne Stroustrup : la GSL (les C++ Core Guidelines) visent à codifier la saine pratique de la programmation à l'aide de C++. Elle ne décrit pas le langage, mais s'intéresse à ce qui devrait tenir compte de saine pratique par défaut (au sens où il faudrait une bonne raison pour faire autre chose). La GSL est tenue à jour entre autres par Microsoft et Red Hat.

Bjarne Stroustrup recommande le recours à des exemples simples qui tiennent sur une seule diapositive, et recommande aussi de ne pas séparer le code des explications; ces explications aident les étudiant(e)s à généraliser leur pensée sur la base des exemples (et, de manière générale, des pages de code sans explications, c'est une perte de temps). Bjarne Stroustrup recommande d'examiner le style de tutoriel mis de l'avant par Brian W. Kernighan et Dennis Ritchie.

Bjarne Stroustrup recommande d'expliquer pourquoi une manière de procéder est préférable à une autre. Il tient pour exemple des boucles for à l'ancienne et les boucles for sur des intervalles : inscrire l'intention à même le code, porter son attention sur l'essentiel. La forme à l'ancienne demeure utile et plus générale, mais réservons-la pour les cas où elle apporte quelque chose.

Bjarne Stroustrup donne un autre exemple, avec un paramètre int (général) et un paramètre milliseconds (plus sémantiquement riche, réduit les risques d'erreur de catégorie). Utiliser des interfaces fortement typées est une avancée, à plusieurs points de vue. Bjarne Stroustrup montre aussi comment C++ permet, par voie de programmation générique, de généraliser à toute unité de temps sans tomber dans une généralisation abusive comme un entier.

Bjarne Stroustrup donne un autre exemple en recommandant d'initialiser les objets à la déclaration, et de les déclarer (conséquemment) au moment opportun. Son exemple utilise les Structured Bindings de C++ 17, et une fonction retournant un agrégat (struct ou std::tuple). Il en profiter pour montrer en quoi les exceptions clarifient le propos dans un programme en permettant de concentrer nos efforts sur l'essentiel. Ceci permet de discuter design (retourner un objet composite avec un code d'erreur si échouer est normal, lever une exception si échouer est atypique).

Bjarne Stroustrup amène un autre exemple qui se veut astucieux et fuit, en mêlant une gestion manuelle de ressources et des pratiques qu'on pourrait au mieux qualifier de désuètes. Ici encore, suivre les conseils de la GSL est pertinent.

Bjarne Stroustrup recommande d'exprimer les idées dans le code, et de conserver les commentaires pour ce qui ne peut être exprimé dans le code. Ceci évite les divergences sémantiques, et évite aussi de faire en sorte que les commentaires n'en viennent à obscurcir le propos. Il montre au passage que la GSL présente un certain nombre de règles d'ordre philosophique.

Bjarne Stroustrup : il est possible d'écrire des programmes C++ à la fois Type-Safe et Resource-Safe, sans payer de coûts indûs.

Bjarne Stroustrup : enseignez en fonction du futur. À la fois les langages, les techniques, les outils. Visez le bon code : correct, facile d'entretien, efficace pour son contexte d'utilisation. Travaillez en fonction de vos objectifs d'enseignement.

Bjarne Stroustrup finit en invitant les gens au panel de demain soir.

Q : comment recommandez-vous d'introduire les étudiant(e)s aux Core Guidelines

Bjarne Stroustrup : choisissez des sous-ensembles pertinents pour les tâches qu'elles / qu'ils auront à accomplir. Raccordez-les à quelque chose de concret pour elles et pour eux. Cela dit, la GSL aura plus de succès quand les analyseurs statiques y seront mieux intégrés. Je veux éliminer totalement les pointeurs flottants (Dangling), par exemple... You will not have to find the rule, as the rule will find you!

Q : le standard offre dans certains cas des solutions appropriées surtout pour des experts, par exemple pour piger des nombres pseudoaléatoires. Devrait-on offrir une bibliothèque spécifiquement destinée aux débutant(e)s, incluant des choses comme rouler un dé, formater des chaînes de caractères, ...

Bjarne Stroustrup : je prêche pour cela depuis des années! (il discute ensuite de la saine utilisation des outils; des gens parlent d'efficacité, mais n'utilisent pas les options d'optimisation de leur compilateur de prédilection; essayez d'écrire du code simple et de laisser l'optimiseur faire son travail).

Q : devrait-on grouper les bibliothèques tiers-parti pour le Web, les interfaces personne/ machine graphiques, les bases de données... devraient-elles être incluses dans le standard?

Bjarne Stroustrup : je souhaite surtout de meilleurs mécanismes pour les trouver, les télécharger et les installer (il lance au passage une flèche aux gens qui ont la brillante idée d'écrire une macro nommée min()). Je préférerais que le standard soit un peu moins « Expert-Friendly »

Q : j'ai participé à un projet avec ma fille (de niveau collégial), incluant du graphique, de la robotique. J'ai créé quelques abstractions pour la démarrer. Malgré tout, il m'a semblé qu'il lui aurait fallu une session entière de C++ pour être à l'aise.

Bjarne Stroustrup : c'est un réel problème, que je pense que l'empaquetage et le déploiement pourraient aider à résoudre. Nous avons aussi besoin de bibliothèques destinées à des débutant(e)s (il mentionne la séance de Sara J. Chipps vendredi soir). Un truc comme Raspberry Pi est génial.

Q : que pensez-vous de l'enseignement de la pensée rigoureuse, par exemple à des mathématicien(ne)s?

Bjarne Stroustrup : c'est important. La programmation et la rétroaction qui l'accompagne peuvent être formateurs pour la pensée abstraite et rigoureuse. L'idée ici est de viser la clarté. Je ne me considère pas l'expert ici.

Q : deux commentaires. De un, j'estime que la GSL est une réelle avancée, mais j'ai eu de la difficulté à la présenter à ma compagnie (le préambule leur a semblé être un obstacle). De deux, oeuvrant dans une industrie fortement régulée, j'ai de la difficulté à faire appliquer la GSL car elle ne fait pas partie du standard et parce que nous avons du code... « Vintage »

Bjarne Stroustrup : oui, le préambule contient une part d'humour; on devrait probablement le retirer. Pour le reste, le vieux code est effectivement un obstacle.

J'ai cessé de prendre des notes car le temps filait et je voulais parler aux organisateurs des problèmes de connectivité au WiFi. Bjarne Stroustrup expliquait aux gens son approche, qui est essentiellement d'apprendre aux étudiant(e)s à écrire une sorte de vector mmaison, puis d'examiner avec eux les enjeux clés associés à une telle classe. Il disait que pour les étudiant(e)s plus avancé(e)s, écrire une sorte de string est enrichissant, ne serait-ce que pour revisiter le design et montrer comment il est possible de faire mieux, par exemple avec SSO. Dans ses mots, il faut en venir éventuellement à faire le lien entre leur code et le modèle mémoire du langage C++, sinon la matière demeure de la magie plutôt que de devenir de la science ou de l'ingénierie.

C++ Constraints: Background, Utility and Gotchas

Walter E. Brown commence par jouer une petite vidéo où des doigts robotisés jouent collectivement de la musique sur un même appareil rappelant à la fois une guitare et une pieuvre. Par la suite, des robots simulés qui ressemblent un peu à des légos jouent de la batterie et de la basse.

Walter E. Brown nous remercie d'être présents. Il pense que requires, les requires-clause et les requires-expression feront partie de nos pratiques à partir de C++ 20. La présentation repose sur ses propositions pour WG21.

Il demande ce qu'il y a de commun entre les termes suivants :

• précondition // constraint
• narrow contract // requires-clause
• wide contract // requires-expression

Walter E. Brown dit que toutes touchent des requis, des attendus. Ils diffèrent, toutefois, en ce qui doit être fait lorsque ces requis ne sont pas respectés.

Une précondition sur une fonction est un requis tenu pour vrai à son point d'appel (ce qui peut être à l'exécution, mais aussi à l'exécution si elle est constexpr). Il mentionne que sqrt() n'a pas, contrairement aux croyances, une précondition à l'effet que son paramètre soit non-négatif, du fait que son comportement est bien défini dans un tel cas; ne pas respecter une précondition est un bris de contrat, entraîne un comportement indéfini. Walter E. Brown indique que Wide Contract signifie aucune précondition, et Narrow Contract signifie au moins une précondition. Il dit s'attendre à voir apparaître [[expects:]] dans le langage éventuellement.

Walter E. Brown dit qu'une contrainte est toujours un contrat statique, et doit absolument être satisfaite. Le code qui s'en servirait ne compilerait autrement, car un composant ont les contraintes ne sont pas respectées n'existe tout simplement pas. Ça ne veut pas nécessairement dire que quelque chose cloche; il est par exemple raisonnable d'exclure délibérément une spécialisation d'un algorithme générique pour certains types.

Walter E. Brown argumente que les contraintes font partie des fondements de C++, où le typage fort est inhérent. On ne peut pas affecter une string à un int, par exemple. Il rappelle static_assert au passage, de même que std::enable_if et les différentes techniques qui en dépendent, ainsi que Expression SFINAE, puis std::void_t (son bébé) avec C++ 17, constexpr if aussi avec C++ 17, et maintenant requires qui s'annonce avec C++ 20. Il rappelle au passage que le mot requires a force de loi dans certains États, ce qui a compliqué l'écriture du standard pour ce qui touche à ce mot.

Walter E. Brown donne un exemple, soit élever une base à un certain exposant connu à la compilation, le tout en réduisant le nombre de multiplications (par exemple, dans le cas où l'exposant est pair). On peut y arriver avec un « helper » qui opère sur les impairs :

template<unsigned N, class T, bool = (N % 2 == 0)>
struct p {
   T operator()(T x) const {
      return x * p<N-1,T>{}(x);
   }
}; // j'ai manqué le reste, mais c'est trivial

Walter E. Brown montre ensuite qu'avec C++ 11, enable_if peut exclure délibérément les cas inappropriés pour une expression donnée. Il montre comment enable_if est exprimé, puis montre comment on peut en tirer profit. Le lien avec SFINAE est expliqué.

Walter E. Brown montre que SFINAE a changé un peu avec C++ 17. Pour instancier un template, le compilateur (a) déduit ou obtient autrement chaque paramètre (il y a quatre manières d'y arriver : les prendre verbatim au point d'utilisation, les déduire des paramètres passés à la fonction, utiliser un Deduction Guide – nouveau avec C++ 17 – et utiliser les paramètres par défaut du template s'il y a lieu), (b) remplacer (substitution) chaque paramètre du template par l'argument correspondant, et (c) si tout a fonctionné, on a un type / une fonction normale. Si la déclaration est bien formée mais échoue à la substitition, SFINAE embarque (ce n'est pas une erreur; on discarte le composant et aucun diagnostic n'est produit). Walter E. Brown donne la parenté du terme SFINAE à Daveed Vandevoorde.

Walter E. Brown dit que SFINAE est principalement utilisé à travers enable_if. L'idée est de faire en sorte qu'un seul des candidats soit tel que ses requis soient satisfaits, et d'exclure silencieusement tous les autres candidats. Il donnt l'exemple suivant :

template <unsigned N, class T>
enable_if_t<N == 0u, T> power(T) {
    return T(1);
} // le reste couvre les cas pair et impair

L'idiome est délicat à appliquer à un constructeur, car il n'y a pas de type de retour (il faut passer par un paramètre, ce qui teinte la signature) et le code est difficile à lire. Dans ses mots, « weird means non-familiar ».

Walter E. Brown  montre que C++ 17 nous donne constexpr if, où les branches non-suivies sont discartées. Il recommande de ne pas les mêler avec static_assert qui, sur le plan grammatical, est une déclaration. Avec constexpr if, il exprime pow<N,T>(T) avec une seule fonction. C'est une nette amélioration, mais il reste encore de l'espace pour améliorer le tout.

Walter E. Brown présente ensuite la TS de Concepts Lite (maintenant simplement Concepts TS), qui introduit le mot-clé requires et les requires-clause. Il dit avoir travaillé pour que requires soit inclus dans C++ 17 mais ne pas avoir gagné ce point. Une clause requires peut être appliqué à n'importe quel template et à n'importe quelle fonction. Un requires-clause induit une contrainte sur un composant, qui doit être satisfaite à la compilation pour que le composant soit instancié puis compilé. Il discute de la sémantique du mot contrainte dans ce contexte (c'est fin sur le plan sémantique, mais intéresant).

Walter E. Brown indique qu'une nouvelle considération est la subsomption, car des contraintes peuvent être interreliées et l'une peut en subsumer une autre. Être « moins contraint » ressemble à être « moins spécialisé » dans le monde des templates. Il fait aussi remarquer que son discours tout entier sous-tend les concepts, qu'il aime, mais n'en dépend pas et peut être utilisé totalement sans les concepts. Il dit ne pas encore avoir vu une véritable description de ce que serait un « bon concept ». Il montre ensuite trois fonctions de même signature, distinctes sur la base de requires (p. ex. : requires local == endian::little). J'aime beaucoup!

Une requires-clause peut contenir n'importe quel prédicat statique, en particulier des traits. Combiner plusieurs requis et les nommer donne un concept. Walter E. Brown montre quelques syntaxes possibles pour les concepts, et montre que certaines sont des raccourcis pour les écritures plus longues reposant sur les requires-clause.

Walter E. Brown montre ensuite comment écrire std::swap(), un cas vécu. Il dit l'avoir écrit avec enable_if, puis avec requires. Il plaide pour que nous utilisons std::swap() plus encore que nous le faisons déjà. Non seulement est-ce une fonction clé, mais c'est un point de personnalisation important. Les corps des fonctions sont identiques, mais les introductions diffèrent. Il a réalisé plusieurs ensembles de tests (gcc, clang, d'autres du domaine privé) et a constaté, à sa grande surprise, des divergences subtiles de comportement.

template <class T> void swap(T&,T&) noexcept(...); // This function "shall not participate in overload resolution unless [T is a movable type]"

C'est une contrainte adressée aux implémenteurs. Traditionnellement, ceci signifie un recours à SFINAE. Walter E. Brown dit que move subsume copy ici.

template <class T> enable_if_t<is_movable_v<T>, void> swap(T&,T&) noexcept(...);

C'est l'écriture classique.

template <class T> requires is_movable_v<T> void swap(T&,T&) noexcept(...);

C'est l'écriture basée sur une requires-clause.

Lors des tests, tout s'est bien passé jusqu'à ce qu'on frappe is_swappable. Ceci fonctionnait avec enable_if, mais pas avec requires. Un exemple du cas problème :

namespace ns { struct A{}; template<class T> void swap(T&,T&) {}}

Walter E. Brown nous invite à considérer :

ns::A a, b; using std::swap; swap(a,b);

Ceci provoque deux lookups, un qui trouve std::swap et un autre qui trouve ns::swap par voie d'ADL. Les deux sont viables, donc il faut les ordonnancer, mais ici aucun n'est meilleur que l'autre et le résultat est ambigu, donc

static_assert(!std::is_swappable_v<ns::A>);

... échoue pour l'implémentation avec requires dû aux nouvelles règles. Maintenant, quand deux candidats existent, le plus contraint gagne la mise. Walter E. Brown mentionne au passage qu'une fonction sans contraintes est comme une fonction requires true. Ici, le test présume un échec, mais avec requires le code est correct car il existe une règle pour lever l'ambiguïté. Les tests doivent (en partie) être repensés!

Walter E. Brown dit que les requires-clause sont plus importantes qu'un simple remplacement pour enable_if. Par exemple, on ne peut pas prendre l'adresse de g() si void g() requires false {}. L'avènement de requires enrichit l'ensemble des règles de résolution du langage. Il y a peu de différences à l'usage enctre enable_if et requires, mais ces différences existent et sont observables.

Q : est-ce que les clauses requires impactent le name-mangling?

Walter E. Brown : le standard ne dicte pas les règles de name-mangling. C'est aux vendeurs de le faire.

Q : dans le cas d'une fonction non-générique, comme celle avec requires local==endian::little, d'où vient local?

Walter E. Brown : j'aurais dû mieux l'expliquer. Dans ce cas, c'esrt une constante globale.

Q : est-ce une bonne idée?

Walter E. Brown : c'est matière à débats. Je suggère que vous présentiez ces idées à des non-experts d'une manière Top-Down, pas Bottom-Up comme je l'ai fait ici.

Q : pensez-vous que requires va subsumer les autres mécanismes SFINAE?

Walter E. Brown : pas entièrement, mais je pense que le nouveau code à partir de C++ 20 reposera de plus en plus sur requires.

Mes notes ne sont que très sommaires ici : je suis arrivé en retard et je devrai partir avant la fin pour mettre en place ma propre présentation.

Les propos portent sur les attentes des participants dans une formation intensive : ça ne sert à rien de toujours en mettre plus si le format est dense, car les gens ne retiendront rien et seront brûlés en fin de parcours.

On demande aux membres du panel pourquoi ils utilsent (ou pas) des exercices. Scott Meyers dit qu'il n'en utilise pas; il faut avoir un objectif pour chaque séance de formation, et les exercices conviennent si l'on souhaite développer des compétences, or dans son cas, on lui demande de former des expert(e)s et de discuter des enjeux, donc les exercices sont moins à propos pour sa clientèle. Kate Gregory dit que dans ses classes, faire des exercices empêche d'être distrait(e) et fait naître des questions, mais qu'elle reconnaît que cette approche est moins adéquate pour des groupes très avancés. Stephen Dewhurst dit comprendre les deux extrêmes, mais pense que les exercices font prendre conscience des cas limites.

Q : j'ai déjà formé des ingénieurs très « C » en C++. En tant que consultants, nous contrôlions parfois la platforme et les outils, mais dans les formations in-situ, nous faisons parfois face à des outils trop anciens pour la matière qu'on nous demandait d'enseigner. Que faites-vous dans de telles situations?

Giuseppe D'Angelo mentionne que dans un tel cas, le temps est probablement mal investi car la matière proposée ne sera pas réinvestie. Scott Meyers suggère d'enseigner comme si tout le monde y avait accès, quitte à montrer des voies de contournement; C++ a le mérite d'être accessible sur une multitude de plateformes, donc on peut distinguer ce que le standard dicte de ce qu'une plateforme donnée supporte. Anthony Williams va dans le même sens, disant qu'au pire, les participant(e)s peuvent souvent l'implémenter par eux-mêmes en attendant une déclinaison standard.

Q  qu'aimez-vous enseigner de C++? Que craignez-vous d'enseigner de ce langage?

Kate Gregory : j'aimais enseigner aux débutants. Dans un cours d'une semaine, le lundi était le plus difficile, et le mercredi était le moment où les lumières commençaient à se manifester. Jon Kalb parle du problème des concepts qui interagissent de manière quasi-circulaire, ce qui demande des actes de foi. Anthony Williams parle de sa passion pour la concurrence, et du plaisir de constater quand les gens commencent à comprendre. Scott Meyers dit aimer quand les gens voient des conséquences inattendues à un nouvel acquis, et mentionne la métaprogrammation (qu'il n'aime pas particulièrement) récursive; il dit ne pas aimer du tout les puits sans fonds de règles comme celles qui touchent à l'initialisationdes variables. Giuseppe D'Angelo dit avoir un faible pour le moment où les gens commencent à mettre la matière en application. Stephen Dewhurst dit aimer les anecdotes qui motivent les gens (il mentionne un incident où dynamic_cast a sauvé Noël... Hum...)

Q : comment briser l'enseignement de superstitions sur la programmation?

Kate Gregory : c'est un peu ce qu'on cherche à faire avec le C++ moderne. Il faut être capables de démontrer les bénéfices. v dit que le rôle d'in instructeur diffère de celui d'un collègue dans une discussion serrée : on ne peut pas se limiter à dire qu'on a un désaccord, il faut expliquer les tenants et les aboutissants. Stephen Dewhurst dit que dans un tel cas, il y a une forme de discours politique à exprimer; c'est difficile, et il faut se mettre dans la peau des gens avec qui l'ont discute : c'est plus efficace que de les critiquer, car il devient possible de cheminer avec eux. Giuseppe D'Angelo trace un lien avec l'excellent keynote de Dan Saks en 2016. Scott Meyers dit qu'il ne croit pas aux argumentaires non-techniques dans une discipline scientifique; il préfère montrer les pour et les contre des alternatives et laisser les gens décider de ce qui sied le mieux à leur propre réalité.

Q : je ne sais jamais combien de théorie intégrer à une formation (trop, pas assez). Mes exemples vont parfois trop loin, et je perds mon audience.

Scott Meyers dit que certains thèmes induisent chez lui un ennui et une distraction instantanée; il recommande de travailler en fonction d'un objectif clair, et de choisir ce qui est utile sur le plan théorique pour porter le message, sans plus, surtout si l'audience est hétérogène. Ce qui ne nous rapproche pas de notre objectif devrait être tenu à distance de notre formation. Jon Kalb mentionne les méthodes virtuelles : il explique ce que ça fait à tous, mais fait attention lorsque vient le temps d'expliquer comment c'est implémenté car ce n'est pas à propos pour toutes les audiences (il indique à tout le moins à son audience qu'une parenthèse sera abordée et qu'elle peut ne pas intéresser tout le monde de manière égale). Kate Gregory dit qu'il faut éviter un long cheminement vers une conclusion à laquelle personne ne portera attention (elle parle de l'enseignement de la syntaxe des λ) : sa suggestion est « Punchline First ». Scott Meyers dit que si on enseigne un truc dont on se servira tout le temps, mieux vaut le dire d'office. Peter Sommerlad, dans la salle, ajoute que ça passe souvent mieux à la deuxième utilisation, où l'on voit les similitudes. Anthony Williams suggère d'avoir deux approches en banque, et faire un choix quand on commence à comprendre notre audience.

Q : certains d'entre vous ont publié des livres. Avez-vous des conseils?

Kate Gregory dit que ça rapporte environ 30$ par mois. Ça ne vaut pas la peine. Il y a des médiums de communication plus efficients. Anthony Williams dit avoir mis quatre ans à écrire le sien, et avoir accepté à reculons de faire une deuxième édition; il mentionne par contre la satisfaction de le tenir dans sa main. Scott Meyers dit ne pas planifier de nouveaux livres, même s'il a fait plus de 30$ par mois avec les siens. Stephen Dewhurst dit avoir eu du plaisir la première fois, et avoir eu une excellente co-auteure, mais ne compte pas en écrire à nouveau. Scott Meyers mentionne que c'est énormément de travail, très satisfaisant quand c'est fini; la publication est un autre enjeu selon lui, et son plus récent volume est vendu en bonne partie (1/3) sous forme électronique. Son éditeur lui dit que les vidéos sont plus en demande maintenant, mais que plusieurs gens achètent (ou téléchargent illégalement) des livres encore aujourd'hui. Kate Gregory dit utiliser deux sortes de livres : ceux qui servent à titre de référence, et ceux qui ont des histoires.

Q : nous enseignons les mathématiques selon un fil différent de celui qui mène aux découvertes. En quoi est-ce similaire ou différent de l'enseignement de la programmation?

Kate Gregory dit l'avoir surtout fait sur la base des outils. Anthony Williams dit qu'il faut intéresser les gens à utiliser une idée ou un concept, alors c'est plus fécond à ses yeux de commencer par un problème concret. Scott Meyers dit que selon lui, ce qui est le plus important en C++ est les destructeurs, et décrit deux approches (les destructeurs résolvent les problèmes suivants; voici des tas de problèmes et, hey, nous avons une solution!) qui peuvent fonctionner ou pas en fonction des audiences. Stephen Dewhurst distingue le processus de découverte, cahoteux et un peu sale, du moment où nous avons une solutio polie et compréhensible, mentionnant que lees deux perspectives peuvent teinter la pensée et l'enseignement.

Which Machine Am I Coding To?

Je vous ferai grâce de mon propos, mais je dirai que j'ai essayé de raccourcir un peu ma présentation (donnée à Montréal cet été) car j'étais très près d'utiliser une heure entière. Cependant, j'ai été trop agressif et j'ai terminé en environ 45 minutes. Heureusement, les gens ont semblé apprécier, j'ai eu des questions amusantes, et j'ai pu rencontrer Fred Tingaud et Matt Godbolt, deux chics types dont j'utilise les outils régulièrement (et dont j'ai mis les outils en valeur pendant ma présentation).

Si vous voulez voir de quoi j'avais l'air, Matt Godbolt a pris une photo (qui montre entre autres que j'utilise son excellent outil) :

An allocator model for std2

(j'ai manqué le début; Alisdair Meredith discute de vitesse d'exécution quand j'entre dans la salle)

Alisdair Meredith : pourquoi vouloir un allocateur? L'opérateur new n'est-il pas suffisant? En fait, c'est souvent suffisant, mais on peut faire mieux en suppléant de l'information contextuelle. On peut aussi bénéficier de certains ajouts de type utilitaire, pour fins de profilage, de débogage, de journalisation ou de tests par exemple.

Alisdair Meredith : un autre cas d'utilisation d'allocateurs est celui des mémoires « spéciales », par exemple la mémoire partagée pour fins de communication inter-processus.

Alisdair Meredith trace ensuite un historique des allocateurs dans le standard. En C++ 98, l'idée était de couvrir les pointeurs near et far de certaines plateformes, et le constat que d'autres cas particuliers étaient susceptibles de survenir. Les allocateurs allouent ds objets, pas de la mémoire, et sont paramétrés sur la base du type à allouer. Chaque allocateur forme un vocabulaire de types. Alisdair Meredith ajoute qu'il y a des Weasel Words dans le standard pour permettre aux implémentations d'ignorer certaines prorpiésés des allocateurs si le contexte s'y prête.

Avec C++ 11, il devenait plus difficile pour une implémentation d'ignorer des propriétés des allocateurs (le Weasel Wording a été retiré). Les allocations passent désormais par des traits, qui offrent un comportement raisonnable par défaut lorsque celui-ci n'est pas explicitement spécifié. Nous offrons aussi un scoped_allocator_adaptor pour les allocateurs imbriqués.

Alisdair Meredith mentionne un cas de Weasel Wording : deux allocateurs d'un même type, avant C++ 11, devaient être interchangeables. Par conséquence, ils devaient être sans états, ce qui compliquait plusieurs cas d'utilisation. Un autre cas était qu'il était possible de présumer des trucs comme is_same_v<A::pointer,A::value_type*>, ce qui est caduque maintenant que la mécanique repose sur des traits. Même rebind est maintenant paramétracle (il y a rebind_traits et rebind_alloc). Le type allocator_traits<A> est tel que tous ses membres sont static, donc nul besoin de l'instancier. Quelques membres discutent de ce qu'on nomme Allocator Propagation.

Alisdair Meredith : est-ce un progrès? Nous supportons maintenant une vaste variété de modèles, mais il y a encore des considérations d'interopérabilité à régler.

Alisdair Meredith : on n'a pas beaucoup touché aux allocateurs avec C++ 14, mais avec C++ 17, nous avons :

• Un trait is_always_equal
• Un raffinement des spécifications d'exceptions sur les conteneurs
• Des Polymorphic Memory Resources (pmr)
• Des conteneurs pmr (pour lesquels l'allocateur ne fait pas partie du type)
• Les pointeurs Fancy doivent être des itérateurs contigus, peu importe leurs autres spécificités

Alisdair Meredith explique ensuite comment pmr fonctionne :

• Une classe abstraite std::pmr::memory_resource dont on dérive
• Le conteneur client entrepose un pointeur sur une implémentation de cette interface
• Le pointeur ne sera jamais propagé (un même allocateur pmr peut survivre à ses clients)

Une présentation des membres clés de cette classe s'ensuit. On y trouve entre autres une constante max_align, dont la valeur est utilisée comme valeur par défaut pour l'alignement dans les fonctions qui réalisent l'allocation de mémoire. Alisdair Meredith des des diapos sur les idiomes avec les classes pmr mais les escamote car le temps file; les éléments clés sont la gestion d'un regroupement (Pool) d'objets qui survivront à leur conteneur, ou un allocateur par défaut pour des objets de durée Thread-Local. Alisdair Meredith nous informe qu'un allocateur pmr ne supporte pas de Fancy Pointers, car l'interface de memory_resource retourne des void* (c'est une perte de flexibilité encourue par le recours à une classe de base). D'autres limites des pmr incluent l'espace requis pour entreposer le pointeur dans les conteneurs, et le recours à du polymorphisme dynamique (mais en pratique, cette dernière n'importe que très peu).

Alisdair Meredith discute ensuite de l'expérience concrète des pmr chez Bloomberg, mais très rapidement.

La question de la complexité des allocateurs de C++ 17 demeure un problème. Alisdair Meredith indique que les facilités trop complexes ne sont pas utilisées en pratique, et mentionne la personnalisation des iostream de même que l'adoption des allocateurs dans la bibliothèque à titre illustratif. Il est aussi irritant de payer un prix pour cette complexité supplémentaire. Le modèle pmr complique aussi la question de la propagation (pour les allocateurs non-pmr, par défaut : jamais, mais paramétrable par voie de traits).

Alisdair Meredith explique ensuite pourquoi la propagation importe. Évidemment, pour un allocateur sans état, la question de la propagation ou pas est sans intérêt. Ne pas propager laisse le conteneur seul responsable des ses éléments; propager change tout, ce qui explique que pour un pmr il soit essentiel de ne pas les propager. Propager peut être complexe en termes de temps d'exécution, et il y a un coîut syntaxique non-négligeable (c'est très Expert-Friendly); entre autres, ça tend à doubler le nombre de constructeurs à écrire pour les conteneurs (car chacun peut recevoir un allocateur avec états en paramètre), et maintenant que nous tenons compte de l'alignement, il est possible d'avoir deux paramètres par défaut. Les Wrappers génériques comme pair et tuple deviennent obligés de tenir compte des allocateurs pour les propager vers leurs éléments. Enfin, certains cas comme std::array et les tableaux bruts ne sont pas supportés, ce qui complique le design d'un vector<array<string>>. D'autres cas douloureux comme optional et variant sont survolés.

Alisdair Meredith propose d'en arriver à un modèle unique d'allocateurs (privilégiant le plus flexible, donc pmr), et de l'associer à tous les objets qui allouent de la mémoire dynamiquement. Il y aurait des types explicitement Allocator-Aware, qu'ils soient marqués en tant que tels ou qu'ils dérivent d'une telle classe, ou qu'ils aient des attributs eux-mêmes Allocator-Aware. Alisdair Meredith vise un approche Implicit-from-Members pour simplifier l'utilisation. Il met de l'avant une API personnalisable pour vérifier qu'un type est Allocator-Aware et obtenir un accès vers le pointeur de pmr.

Selon Alisdair Meredith, il faudra inscrire le pointeur à la construction, quitte à personnaliser le contrôle de l'espace que ce pointeur occupera. Ceci permettrait entre autres de ne pas accroître l'espace occupé dans un objet pour tenir compte du pointeur (ça pourrait être fait de manière externe, étant associé au type plutôt qu'aux instances). On pourrait mettre le tout en branle même avec C++ 98. Alisdair Meredith discute rapidement d'un mécanisme d'injection d'allocateurs, passant pas un paramètre caché à la construction, ce qui ne polluerait pas l'interface des objets Allocator-Aware. Son modèle (informel) reposerait sur des attributs comme [[injects(allocator)]] ou [[injects(from_stack)]] étant donné des instances d'allocateurs ainsi nommé qui, s'ils sont absents, déférerait à l'allocateur par défaut. Cet attribut pourrait aussi être inséré dans un appel à new, comme dans new[[injects(from_stack)]] X;

Le reste de la présentation doit être abrégé (Alisdair Meredith en a trop mis), mais discute d'optimisation de cas spéciaux. J'ai hâte de voir les diapositives.

Q : dans le cas d'un vector<string>, pourrais-je dire « ne déalloue rien quand le vecteur mourra; laisse l'allocateur s'en charger »

Alisdair Meredith : on écrit alors un allocateur optimisé spécifiquement pour ce scénario.

Q : dans [[injects(from_local)]], vise-t-on un Small Vector ou un Arena?

Alisdair Meredith : je parlais d'un objet local au contexte dans cet exemple. C'est là que la logique serait déterminée. Ce n'est pas nécessairement de la mémoire sur la pile.

From security to performance to GPU programming: exploring modern allocators

Sergey Zubkov commence par expliquer ce à quoi sert un allocateur, ce que cela fait concrètement (politiques d'allocation, de libération, de construction, de destruction) et distingue les allocateurs traditionnels (statiques, inscrits dans le type du conteneur) et allocateurs pmr de C++ 17.

Sergey Zubkov montre ensuite quelques cas d'utilisation. Il présente secure_allocator, qui verrouille la mémoire sur allocation (pour éviter qu'elle soit permutée ailleurs) et qui la réinitialise sur libération. Il mentionne plusieurs utilisateurs de telles stratégies (Bitcoin, JsonCpp et d'autres), et montre comment il est possible d'en profiter pour réellement sécuriser la mémoire (SecureString, qui est une basic_string<char,secure_allocator<char>>).

L'exemple suivant est un programme qui alloue beaucoup d'objets (producteur, consommateur) à travers des shared_ptr et s'exécute pour une longue période sans interruption (un an, disons). Que se passe-t-il? On a une sale fragmentation de la mémoire. Il présente en réponse std::pmr::polymorphic_allocator<T>(&pool) où pool est un std::pmr::synchronized_pool_resource et utilise std::allocate_shared<T,A> pour réaliser l'allocation à proprement dit. Ceci réduit sa consommation de mémoire par un facteur de 1000.

L'exemple suivant utilise tbb::scalable_allocator<T>. Sergey Zubkov mentionne que des tas privés par thread (ségrégation entre les tas) peut significativement améliorer le temps d'exécution dans certains cas multiprogrammés. On parle encore une fois d'un Pool Allocator, mais avec des caractéristiques différentes.

On poursuit avec boost::interprocess::allocator, pour partager un conteneur entre plusieurs processus. Ça passe par un boost::interprocess::managed_shared_memory. Les segments sont nommés à la construction (par une fabrique), et trouvés (dans d'autres processus) par leur nom. Sergey Zubkov montre ensuite comment ce mécanisme fonctionne avec des conteneurs imbriqués, en utilisant un std::scoped_allocator_adaptor bien entendu.

Ensuite vient une discussion de Fancy Pointers, quand on a par exemple on boost::interprocess::offset_ptr<T> plutôt qu'un T*. Le type discuté est indépendant de l'adresse réelle d'un objet pointé, se basant plutôt sur un delta avec un point de référence.

Autre cas exploré: boost::compute::pinned_allocator, avec un Fancy Pointer de type device_ptr<T> qui tient à jour un objet composite fait d'une référence à un Device Buffer et d'un index.

Sergey Zubkov montre ensuite qu'il y a des centaines de tels allocateurs utilisés en pratique. Il en profite pour rappeler aux gens qu'il est sage d'apprendre à les connaître, pour ne pas se trouver en situation de devoir réinventer la roue sans cesse. Il mentionne au passage que nous avons six (!) présentations distinctes sur le sujet des allocateurs à CppCon cette année.

Q : si on écrit un type souhaitant utiliser un allocateur, c'est un effort coûteux. Avez-vous quelque chose à suggérer pour alléger cet effort?

Sergey Zubkov (je n'ai pas compris la réponse)

Q : existe-t-il des allocateurs qui génèrent des problèmes de manière pseudo-aléatoires?

Sergey Zubkov pense que si.

Q : dans le cas de boost::compute, qu'obtient-on réellement quand on déréférence un Fancy Pointer?

Sergey Zubkov pense que c'est un pointeur nul (il me semble; il ne parle pas fort)

Les discussions qui suivent visent à clarifier les raisons des gains de vitesse par un facteur de 1000 dans l'exemple susmentionné.

Je ne prendrai pas de notes détaillées sur cette présentation, du fait que je vais en manquer une bonne partie, mais le présentateur survole ce qu'est le Fuzzing, quelles sont les principales formes de Fuzzing, à quoi ça sert en C++ (en gros, c'est une question de sécurité; il mentionne le ver Heartbleed et les dégâts qu'il a causés). Il utilise même le vocable (honni!) C/C++ du fait que les bogues de sécurité de C++ auxquels il s'intéresse ici proviennent pour l'essentiel de C.

À la suggestion que le C++ moderne échapperait à ces bogues, il donne un exemple prenant un string_view non-évanescent sur un string&& résultant de la concaténation d'un string avec un const char*.

Jon Kalb commence par demander aux membres de se présenter et de décrire leur rôle sur le comité. Je vous passe les réponses. Les membres ce soir sont Eric Niebler, Louis Dionne, Gor Nishanov, Gabriel Dos Reis, Bjarne Stroustrup, Herb Sutter, Andrew Sutton, Ville Voutilainen et Titus Winters. Gor Nishanov, Eric Niebler et Louis Dionne sont particulièrement bien reçus, en lien avec leurs travaux sur les coroutines, les intervalles et la combinaison de réflexivité et de métaprogrammation. Bjarne Stroustrup est applaudi pour l'ensemble de son oeuvre, et tient un discours plutôt amusant sur la difficulté de faire progresser les dossiers qui lui tiennent à coeur dans un comité de la taille et de la complexité de WG21. C'est intéressant de remarquer que c'est celui qui pousse le plus fort pour l'évolution du langage dans des directions radicalement novatrices. Herb Sutter met de l'avant ses travaux récents sur la simplification de la programmation.

Jon Kalb : vous portez deux chapeaux, soit porter des propositions et résister à des propositions. Pouvez-vous donner un cas où vous avez initialement rejeté quelque chose qui, éventuellement, en valait vraiment la peine?

Eric Niebler : j'ai flotté mes efforts portant sur les intervalles à travers les réseaux sociaux, et je trouvais le tout merveilleux, mais un individu nommé Sean Parent a soulevé des préoccupations. Nous avons tous deux résisté l'un à l'autre, pour éventuellement nous rencontrer au centre. Le tout est infiniment meilleur maintenant grâce à ce dialogue.

Bjarne Stroustrup : c'est la mauvaise question. Il faut d'abor articuler le problème, puis discuter (dans le comité, hors du comité) des cas d'utilisation pour faire émerger les solutions qui constituent du bon code. La syntaxe plus précise, les cas limites viennent ensuite; j'estime que le désir de perfection du comité actuel nous ralentit, et que nous pourrions avancer plus rapidement en nous concentrant sur les considérations plus fondamentales.

Ville Voutilainen : pendant la standardisation de C++ 0x, nous avons flotté l'idée de noexcept(auto), que j'ai ramené pour C++ 14. Bjarne Stroustrup a demandé pour qui c'était. Je lui ai dit que j'en avais besoin à quatre ou cinq endroits. Il m'a demandé si l'adoption ou pas du mécanisme serait un fardeau. J'ai dit non. J'ai convenu d'enterrer le tout.

Herb Sutter dit que quelqu'un cette semaine a dit compter apporter une proposition pour restrict. Il faut que ce soit autre chose que le restrict de C99. Bjarne Stroustrup dit que la forme actuelle de restrict signifie Trust Me; c'est une sorte de cast, qui ne fonctionne pas bien avec le système de types. À son avis, toute proposition pour restrict sera un combat; même Dennis Ritchie avait résisté à cela en C. Bjarne Stroustrup pense que ce mécanisme n'a pas sa place dans le Core Language.

Odin Holmes dit que les générateurs de code sont typiquement difficiles à déboguer, incluant les mixins de D et son propre code métaprogrammé. Il soulève la question pour les métaclasses de Louis Dionne et Herb Sutter. Louis Dionne, qui adore la métaprogrammation, demande s'il existe quelque chose de plus difficile à déboguer que de la métaprogrammation; selon lui, le problème en est un de Quality of Implementation, et les débogueurs s'adapteront. Herb Sutter dit qu'il parlera de ce problème lors de sa présentation cette semaine; il rappelle qu'il faut considérer ce que ces mécanismes remplacent, et émet le souhait que nous en arrivions à plus de métaprogrammation, mais moins de Template Metaprogramming. Herb Sutter ajoute que déjà aujourd'hui, avec un débogueur, nous savons comment interagir avec les entités générées par le compilateur comme les constructeurs de copie implicites. Titus Winters rappelle l'importance des revues de code; il voudra passer d'une perspective à l'autre lors des revues de code (métaclasses, code généré). Gabriel Dos Reis trouve la question importante, au sens où ce qui est fait à la compilation s'évapore à l'exécution. C'est un défi pour nos outils. Gabriel Dos Reis trace un parallèle avec Lisp, où le Compile-Time et le Run-Time se confondent, et rappelle cette beauté qu'est constexpr et qui apporte quelque chose de semblable (mais adapté au contexte) dans C++. Bjarne Stroustrup rappelle que nous souhaitons mettre fin aux critiques à l'effet que C++ soit un langage Write-Only; l'effort de simplification au coeur des travaux des dernières années se poursuit. Bjarne Stroustrup rattache les travaux sur les concepts à son discours (à juste titre). Il rappelle l'importance d'éviter une dégénérescence du langage en divers dialectes, dans une perspective de composabilité des programmes. Selon lui, un moteur de sérialisation devrait ressembler à une fonction acceptant une instance d'un type et itérant, en quelque sorte, sur ses membres d'instance. Herb Sutter rappelle que Make Simple Things Simple semble simple, justement, mais est un objectif très difficile à atteindre, surtout si on considère les cas d'utilisation, l'entretien... Bjarne Stroustrup souhaite une réflexivité de base pour C++ 20 (Herb Sutter réagit; c'est une position ambitieuse!). Eric Niebler parle de la difficulté de raisonner à de très hauts niveaux d'abstraction, mais rappelle que nous le faisons régulièrement pour les abstractions que nous maîtrisons comme les méthodes virtuelles. Herb Sutter se dit d'accord, mais insiste pour que les abstractions soient à coût zéro, sinon elles n'ont pas leur place dans C++.

Q : l'oppostion à restrict me semble justement être un cas où nous faisons de quelque chose de simple quelque chose de complexe (surtout dans la perspective suspecte de C). J'aime aussi beaucoup les Value Parameters autres qu'entiers dans les templates, alors quand les aurons-nous?

Bjarne Stroustrup recommande de les demander plus fort. Gabriel Dos Reis dit qu'on les veut mais qu'on a plusieurs gros dossiers sur la table que nous souhaitons faire avancer, mais mentionne qu'ailleurs dans le langage, il n'y a pas de différence de fond entre int et complex<double>. Bjarne Stroustrup dit que c'est un enjeu de priorités. Ville Voutilainen liste les enjeux pour éviter que cette considération évite les conflits d'ODR, ce à quoi Gabriel Dos Reis dit qu'il y a des solutions mais que le comité n'est pas d'accord sur la poste à suivre. Louis Dionne pense que la clé serait de lier cela aux types assujettis à constexpr, et indique qu'une progression par Jeff Snyder à ce sujet fait son chemin. Herb Sutter mentionne l'importance d'avoir des cas d'utilisation concrets; il indique que pour certains cas d'utilisation, il existe des solutions dans le langage existant qui peuvent être plus adéquates que le mécanisme demandé. Louis Dionne trace une subtilité associée aux paramètres constexpr, que nous n'avons pas encore, ce qui nous empêche de bien propager le caractère constexpr de certains objets. Bjarne Stroustrup demande un vrai cas d'utilisation (on répond des Compile-Time Format Strings à la Rust, mais quand l'explication détaillée apparaît, le tout devient très complexe et Bjarne Stroustrup recommande de chercher des cas d'utilisation plus simples, qui recoupent des besoins plus directs, avant de placer la demande tout en haut de sa pile de priorités). Titus Winters plaide pour une approche plus moderne que des Format Strings.

Q : quand nous avons une proposition d'envergure, par exemple les modules ou les concepts, comment peut-on garder le « momentum »?

Gabriel Dos Reis dit que c'est difficile; le simple fait de bien définir le problème à la communauté est une chose ardue. Il faut rester concentrés. Bjarne Stroustrup dit que ce qui le motive personnellement à travailler sur un même problème pour une vingtaine d'années ne vient pas du comité, qu'il perçoit plus comme un obstacle à surmonter, qui nous rappelle trop souvent que nos bonnes idées ne sont pas nécessairement aussi bonnes que nous le pensions au préalable. Il parle ensuite de son approche pour ce qui est de choisir un problème sur lequel concenter ses efforts, et de son approche pour les solutionner. Cela dit, pour le tenir occupé pendant vingt ans, il lui faut des considérations plus profondes, plus fondamentales comme les concepts, les modules ou la réflexivité statique. Eric Niebler dit que pour les intervalles, débutés il y a quatre ans, la rétroaction (positive) des usagers s'est avérée être une forte source de motivation. Il rappelle qu'à son point de vue, il y a généralement parlant trop de complexité dans le monde de la programmation. Gor Nishanov dit que c'est la douleur qui le motive, et le souhait de réduire la douleur (Ville Voutilainen fait remarquer que cela signifie que le processus de standardisation des coroutines est sans doute un moindre mal; on se bidonne un peu). Andrew Sutton a travaillé sur les concepts pour six ans; il apprécie la rétroaction (constructive) des usagers, et apprécie moins les Bug Reports.

Jon Kalb signale qu'il faudra raccourcir les réponses cas le temps file.

Q : comment détermine-t-on ce qui sera accepté dans le langage et ce qui ne le sera pas?

Bjarne Stroustrup dit que c'est un enjeu de priorités. Herb Sutter mentionne que le problème soulevé dans la question (la présence de macros pour and, or, not) est une question supportée par C.

Q : le formatage des iostreams en surchargeant l'opérateur << ... Est-ce sacré? Pouvons-nous envisager quelque chose de plus « utilisable »?

Titus Winters dit que son équipe s'en passerait bien. Ville Voutilainen dit que tout est possible étant donné une proposition bien écrite. Bjarne Stroustrup rappelle que les iostreams sont une solution des années '80, et que la bonne approche ne sera pas une solution des années '70. Il faut faire mieux.

Q : pourquoi est-ce difficile de standardiser les atomic_shared_ptr?

Herb Sutter dit que ça suit son cours en vue de C++ 20. Les craintes avaient trait aux cas d'utilisation.

Q : What the Hell is a Monad?

Herb Sutter : tu te trompes de comité. Eric Niebler : It's a Monoïd in the Category on Endofunctors.

Q : j'entends que le recours à C pour les systèmes embarqués est un problème de marketing. C'est vrai pour le langage, mais est-ce aussi vrai pour les bibliothèques? Il y a uin enjeu de confiance quand on ne voit pas l'implémentation des fonctions appelées...

Gor Nishanov dit que plusieurs utilisent le langage mais pas les bibliothèques; il mentionne que SG14 travaille là-dessus. Bjarne Stroustrup mentionne que C ne fait pas mieux, alors c'est un véritable problème de marketing. Gabriel Dos Reis dit qu'il est vrai que pour certaines clientèles, voir les sources est important. Titus Winters dit qu'il faut savoir ce que les bibliothèques nous offrent; il en parlera dans sa présentation demain. Ville Voutilainen dit que plusieurs travaillent déjà sur ce dossier.

Q :  en C++, nous sommes capables d'exprimer certaines caractéristiques comportementales (this function shall not throw...). Le code de haut niveau souhaite en savoir plus sur le code de bas niveau. Qui travaille là-dessus au juste?

Ville Voutilainen mentionne les contrats. Bjarne Stroustrup dit que le langage décrit ce qui est possible, pas comment le faire. Une partie de la réponse à cette question lui semble donner dans les Guidelines. Herb Sutter ajoute les concepts à la liste des éléments de solution.

Q : aura-t-on decltype(lambda-expression)?

Louis Dionne travaille sur la cinquième itération de cette proposition.

Q : qu'est-il advenu du Unified Call Syntax? D'autres langages ont une solution...

Bjarne Stroustrup dit que les gens sont plus préoccupés par le passé que par le futur. Titus Winters dit que ça complique la rédaction de bilbiothèques. Herb Sutter parle de l'équilibre entre le code existant et l'écriture du code futur; il faut un Fallback pour ne pas perdre la compatibilité avec le code existant, et on provoque un cas de Name Hiding. Pour les autres langages, Python n'aime pas nécessairement beaucoup la solution existante. Ville Voutilainen mentionne que C# était bien jeune quand les méthodes d'extension ont été introduites. Herb Sutter rappelle que C# n'a pas de fonctions globales; c'est un cas d'utilisation intéressant, mais radicalement différent.

Q : le comité compte-t-il discuter des métaclasses?

Herb Sutter dit que le comité en a parlé une première fois à Toronto 2017. La réflexivité arrivera sur la table en premier lieu.

Q : pourquoi donne-t-on dans le comportement indéfini quand une fonction non-void n'a pas de return? Ne devrait-on pas refuser de compiler?

Gabriel Dos Reis dit que les compilateurs pourraient rapporter ce problème en pratique.

Q : devrait-on utiliser un Safe-Chaining Call Operator (comme le ?? de C#)?

Ville Voutilainen dit qu'on pourra en discuter en présence d'une proposition. Herb Sutter dit qu'on le fait avec =delete.

Everything You Ever Wanted to Know about DLLs

James McNellis liste ce que nous ferons (la liste est longue) et ce que nous ne couvrirons pas (.NET, les .so de Linux).

James McNellis : une DLL est une bibliòthèque. Ça contient du code et des données, mais on la charge dyamiquement et ça peut être partagé entre plusieurs programmes.

James McNellis : l'idée est d'économiser de l'espace en mémoire et sur disque. Ça peut aussi nous permettre de ne charger un module que si le besoin s'en fait sentir. Enfin, ça permet de séparer le développement en composants, de les développer concurremment et de mettre à jour les programmes par morceaux.

James McNellis : évidemment, ça complique le code, et ça introduit des risques d'incompatibilité (le DLL Hell). De même, ça rend certaines optimisations impossibles.

James McNellis crée ensuite une DLL à la ligne de commande. Examinez sa présentation pour les détails.

James McNellis présente la structure interne d'une DLL, puis présente quelques outils pour en examiner la structure binaire. En particulier, dumpbin /headers est parlant.

James McNellis parle ensuite d'adressage dans une DLL. Le format interne est présenté graphiquement. L'enjeu est que les DLL peuvent être chargées un peu partout (pseudoaléatoire) dans un processus, pour raisons de sécurité, alors les éléments d'une DLL ont une RVA (Relative Virtual Address) permettant de les localiser une fois l'adresse de base de la DLL connue.

James McNellis montre ensuite d'autres options de dumpbin, pour entre autres voir le code machine de certains éléments.

James McNellis donne des exemples de chargement dynamique implicite et explicite. Il montre aussi des exemples de #pragma comment(linker,...) au passage (je ne connaissais pas).

James McNellis montre un programme contenant deux appels à LoadLibrary() puis deux appels à FreeLibrary(), pour montrer qu'un seul chargement a lieu (il y a un compteur de références par processus dans la mécanique) et que le déchargement se fait lors du dernier FreeLibrary() seulement. Il faut être prudent quand deux DLL du même nom existent mais sont accédées sur des chemins différents (la première chargée gagnera). La mécanique de recherche d'une DLL dans le système de fichiers est expliqué.

James McNellis aborde ensuite le rôle de DllMain() lors de la connexion ou de la déconnexion d'un thread ou d'un processus, puis distingue les liens explicites (GetProcAddress()) et implicites (__declspec(dllimport)).

James McNellis aborde la question des variables globales dans une DLL, et l'insertion de leur construction et de leur destruction dans le cycle de vie de la DLL elle-même. Il montre qu'il est possible d'exporter des fonctions et des classes écrites en C++, surtout vers des programmes écrits en C++ et conscients du name mangling appliqué à l'origine. James McNellis recommande toutefois de ne pas le faire (entre autres, l'ABI n'est pas stable; COM ou WinRT sont de meilleurs candidats).

Q : peut-on partager les données dans une DLL?

James McNellis : oui (il explique la mécanique, en particulier en présence d'adresses pseudoaléatoires). Il dit que kernel32.dll le fait.

Q : recommandes-tu dllexport ou pas?

James McNellis : je préfère les .def, surtout pour définir un contrat stable.

Q : est-ce que je risque un interblocage à la construction d'une globale dans une DLL?

James McNellis : ça dépend. Ça peut se faire mais il faut être prudent, surtout avec des outils tiers partis.

C++ as a "Live at Head" Language

Chandler Carruth présente Titus Winters en racontant une anecdote. Chandler Carruth se dit d'avis que les outils ne changent pas le monde, et dit que Titus Winters a transformé son équipe technique en une force plus grande; il dit que Titus Winters lui a montré comment écrire du meilleur code C++.

Titus Winters dit qu'il veut tracer un historique du développement avec C++ chez Google. De 2006 à 2010, la portabilité n'était pas vraiment une préoccupation. De 2000 à 2006, le focus était de créer de chouettes outils. Maintenant, le monde mobile amène de nouvelles exigences, et il en va de même pour l'infonuagique. Maintenant, l'objectif est de publier des outils et des bibliothèques, d'une manière qu'il sera possible de soutenir et de maintenir à long terme.

Titus Winters distingue le génie logiciel de la programmation. Il dit que pour lui, Engineering is Programming Integrated Over Time. Il présente l'évolution des pratiques lorsqu'un champ est requis dans un message. Je ne peux pas bien montrer le procédé qu'il décrit, c'est un peu visuel. L'ingénierie logicielle doit résister au passage du temps (tests, refactorisation, schémas de conception, contrôle des versions, etc.). Le contrôle des versions et des requis est décrit en détail. Titus Winters mentionne qu'un simple ajout ou retrait d'une ligne vide peut être un Breaking Change quand le code dépend d'un truc comme __LINE__...

Titus Winters parle d'autres Breaking Changes : ajouter une surcharge, changer la taille ou l'alignement d'un objet, supprimer une API, etc. Il en vient à parler de Semantic Versioning, et de la gestion du changement dans le cas de « dépendances en diamant » (une base, deux modules qui en dépendent, un module qui dépend des deux précédents) : il est difficile d'identifier les changements à faire (où? quoi? comment le tester?).

Titus Winters aborde la question de la compatibilité avec les déclarations a priori (comme <iosfwd>), et montre une fonction is_even() terriblement mal écrite, mais dont le sens est brisé depuis C++ 17 car elle dépend du type de retour de la méthode emplace_back() d'un vector (sans commentaire).

Titus Winters en arrive au coeur du propos : quelles sont les garanties de stabilité que le standard vous offre?

Dans std, n'ajoutez pas de noms

Dans std, ne faites pas de déclarations a priori

Dans std, présumez une interface Call Only (ne prenez pas l'adresse des fonctions, de faites pas d'introspection sur les types).

Titus Winters présente Abseil, une bibliothèque sur laquelle des millions de lignes de code et des milliers de développeurs comptent. Il nous indique que l'ABI ne sera pas stable et que tout ce qui est interne est sujet à changements. Il la présente comme un outil à zéro configuration, incluant du code utilitaire, des fonctions applicables à des strict, respectueuses des Core Guidelines, et des versions C++ 11 d'outils plus récents. L'objectif est de supporter le code du passé, dans un horizon de cinq ans. Divers outils en font partie (Address Sanitizer et autres). Les types de absl:: sont compatibles avec les types de std:: en tout point, et sont ds alias pour ces derniers lorsqu'ils existent.

(j'ai arrêté de prendre des notes car ça devenait une espèce de promotion d'un outil; c'est plus ou moins ce que j'aurais aimé voir en plénière, même si l'idée est intéressante)

Le laïus se termine sur une recommandation de resserrer les efforts de gestion du changement.

Q : comment Abseil se comportera-t-elle lors de levée d'exceptions? (Google ne les supporte pas, règle générale)

Titus Winters : je ne pense pas que nous ayons rencontré de problèmes.

Q : que pensez-vous de la syntaxe uniforme des fonctions?

Titus Winters : je trouve que ça interopère mal avec le code de bibliothèques tierces.

Q : vous avez parlé de Call Only Interfaces. En C++, on tend à faire is_contructible_v<T> plutôt que chercher à appeler T{}.

Titus Winters : si vous souhaitez dépendre de quelque chose de spécifique, écrivez-nous un courriel.

(je manque quelques questions difficiles à comprendre; quelqu'un fait remarquer que le recours au Pascal Case / Snake Case dans Abseil en fait un No Go, et on rit un peu)

Postmodern C++

J'attendais cette présentation avec impatience. Je ne sais pas si je parviendrai à prendre des notes. C'est une nouvelle version d'une présentation qui a gagné des prix plus tôt cette année, et c'est à la fois brillant et surréaliste, et postmoderne (Derrida s'inflitre dans le texte, avec la différance et la déconstruction; il me cite au passage, de même que Jonathan Caves, JF Bastien et plusieurs autres; il parle d'architecture; et plein de trucs brillants se passent). L'essentiel du propos est véhiculé par des tweets. C'est plein de rimes (en fait, ça rime du début àla fin... Wow!), et c'est carrément brillant. Bruce Lee apparaît à l'occasion, Dr Seuss aussi.

Sérieusement, probablement la meilleure présentation à laquelle j'ai pu assister. Difficile d'envisager le temps que ça lui a pris. Même les pauses sont calculées... Wow, vraiment!

À la fin, il intègre à sa conclusion une métacritique de sa présentation. Su-per-be! Durant cette période, il met un peu (pas totalement!) les rimes de côté (il a quand même rimé pendant une demie-heure!).

S'ensuit une analyse de son analyse! Une solide (et stupéfiante!) démonstration d'intelligence, d'humour, de philosophie, de science et d'absurde.

Les questions de la salle portent sur la couleur des poissons, sur le Crappy Gabon Paper... Une question est exprimée en rime! Certaines questions sont plus profondes, menant par exemple à la suggestion que variant devrait être un type primitif. Questionner ses propres pratiques, réfléchir avant de coder, s'auto-référencer...

Tony Van Eerd a des Bonus Slides faites de Koan de programmation C++. Du bonbon!

Designing A Feature That Doesn't Fit

Je vous passe les détails, mais ça s'est bien déroulé. La salle était pratiquement pleine, je pense avoir donné un bon show, j'ai mieux géré mon temps que la veille, et même si le sujet n'était pas particulièrement technique, il a semblé rejoindre beaucoup de gens sur place.

Recreational C++

Alisdair Meredith présentera des petits puzzles qui font réfléchir. Il les distingue de Toys and Pets, qui sont de petits projets comme écrire un programme de clavardage par exemple; ses puzzles sont bien plus petits.

Alisdair Meredith parle de ses mauvaises habitudes : il lit la bibliothèque standard avec chaque nouveau standard et cherche des puces.

Alisdair Meredith : implémentons un trait. De manière minimaliste. Existe-t-il une manière minimaliste? Il parle de std::is_function_v<T>, un variable template variadique sur le nombre de paramètres. Son premier jet ne dérive pas de std::integral_constant, ce qui est un irritant. Il démontre une bibitte nommée awkward<T> qui dérive de is_object<T> et de is_enum<T>... qui n'est pas conforme dû à un cas limite agaçant. Sa signature de type inclut un ...... pour tenir compte des ellipses du langage C... Ouch! Et il en faut deux pour couvrir noexcept, puis les versions const, volatile et const volatile, et les combinaisons & et &&. Certains cas sont des laquo; fonctions abominables raquo; (c'est le terme technique, sans blagues)... Et on n'a pas encore parlé des comventions d'appel, ou des fonctions extern "C"! Il arrive à 48 cas, juste pour les cas portables... Quelqu'un suggère d'utiliser std::remove_cv<T> mais ça ne nous aiderait pas car les fonctions membres ne sont pas vraiment cv-qualifiées ici (c'est l'objet référé qui l'est). Il montre l'implémentation de clang, qui y va par élimination... de 13 ou 14 cas. Eric Niebler a une solution plus charmante avec types énumérés indicés qui parcourent de manière statique les cas possibles de surcharge.

Alisdair Meredith explique pourquoi il a généré 10'000 types pour les fins de ses tests : il a utilisé des objets, des qualifications, des références, des pointeurs, des tableaux de chacun, etc. Ajoutons à ceci une variété de nombres de types de paramètres, ça en fait beaucoup. Faut aussi couvrir les constructeurs correctement. Le pire : la solution d'Eric Niebler échoue avec un tableau de types incomplets, qui est légal dans le système de types mais est rapporté comme une fonction.

Alisdair Meredith en est arrivé à une solution qui tient dans un tweet, en vérifiant que T et const T sont pareils, puis en validant !is_const_v<const T>&&!is_reference_v<T>.

Alisdair Meredith montre ensuite des Benchmarks sur son is_function_v<T> tout simple : vitesse de compilation, taille de l'exécutable, et aimnsi de suite. Tristement, sa solution n'était pas plus rapide que celle, beaucoup plus complexe, de clang.

Le défi suivant est de définir is_integral_v<T> sans épuiser la liste des 15 cas, avec en plus les cas non-standards et les variations const et volatile, le tout sans englober des trucs comme les énumérations, les pointeurs ou les références qui sont sémantiquement distincts. On jongle avec plusieurs options. Alisdair Meredith suggère de commencer par is_arithmetic_v<T>, qui couvre plus large. Son intuition est qu'il n'est pas possible de surcharger les opérateurs sur un primitif; il suggère donc d'écrire un Sniffer pour détecter l'impossibilité de surcharger operator+(T). Sa technique repose sur void_t<+decltype(T){})> (ceci permet d'ailleurs presque pour définir is_arithmetic_v<T>), mais ça n'exclut pas les pointeurs alors il passe plutôt par operator*(T,T). Puisque C++ ne supporte pas modulo sur des nombres à virgule flottante, il règle le problème d'exclure ces derniers avec essentiellement la même technique.

Alisdair Meredith examine ensuite std::pair à travers les versions du langage, car std::make_pair() a changé à chaque étape : C++ 98 (accepter comst T&,const U&), C++ 03 (accepter T,U pour couvrir les auto_ptr), C++ 11 (accepter T&&,U&&) et C++ 14 (rendre la fonction constexpr). Avec C++ 17, les Deduction Guides interviennent.

Alisdair Meredith suit avec une discussion de l'implémentation de std::get<I> pour des pair (pour bien le faire, il faut traditionnellement une couche intermédiaire). Ceci met en valeur la beauté de if constexpr. Il examine ensuite comment extrapoler std::get<I> sur un tuple. Il passe alors par un wrapr<T> avec des opérateurs de conversion en T&,T&&,const T& et (cas dégénéré) const T&&. Il traite ensuite pair comme un tuple. Il discute ensuite de manières de tester son implémentation pour vérifier sa conformité avec le standard. L'étape suivante est d'ajouter des contraintes, avec par exemple requires de C++ 20.

Nous discutons ensuite de conventions de programmation : indentation, disposition du code, noms... Il plaide pour and au lieu de && pour éviter la confusion avec les rvalue references. Il plaide pour using en remplacement de typedef. Il discute de class ou de typename pour les types génériques, et des options d'enum class ou enum struct. Alisdair Meredith préfère struct et typename (pas moi!).

Le sujet suivant est l'indentation. Il montre le style Simon Peyton Jones (non, juste non). Alisdair Meredith montre que ça peut marcher avec C, mais que c'est un désastre avec C++.

Discussion suivante : auto partout ou pas. Alisdair Meredith donne sa perspective sur le sujet. En gros : cool pour le code générique. On discute par la suite de signatures de fonctions (où placer le type, auto ou pas... auto f() -> void gaspille de l'espace pour rien!).

Un exercice : écrire la plus longue phrase possible avec seulement des mots clés et de la ponctuation. Il arrive à dix mots : do not try this volatile auto union case, or else.

On termine là-dessus, en riant.

Je n'ai pas pris de notes, évidemment, étant sur le panel. J'ai parlé de l'enseignement de la programmation dans le modèle québecois, du rôle des Cégeps, dans une branche préuniversitaire et dans une branche technique, de nos programmes techniques jusqu'ici et du proche futur (nous avons un nouveau programme à l'horizon), de ce que je fais avec mes étudiant(e)s de premier et de deuxième cycle universitaire, etc. Je pense que les gens ont trouvé ça intéressant. J'aime bien notre modèle d'ailleurs; on peut grogner, se plaindre, vouloir s'améliorer, mais en pratique je trouve que les comparaisons nous avantagent souvent.

Pour certains de mes collègues enseignant(e)s, sachez que j'ai eu un échange avec l'un des individus derrière Unreal Engine, qui est utilisé dans certains des contextes d'enseignement à l'intérieur desquels j'interviens. Je lui ai dit pourquoi je les aime, et pourquoi je ne les aime pas; nous avons bien ri. Chic type. J'ai aussi bavardé avec un individu qui travaille à Ubisoft Toronto et un autre qui vient de France et s'est installé récemment à Vancouver, deux autres chics types.

Je suis par contre ressorti un peu triste du panel, où les présentatiomns initiales m'ont semblé trop longues et où il ne me semble pas y avoir eu assez d'espace pour les interactions avec les gens dans la salle.

Ce panel n'était pas filmé.

Michael Wong dirige les travaux. Nous préparons un ordre du jour visant à accommoder les présentatrices et les présentateurs potentiel(le)s, car certain(e)s ont des présentations à donner dans le cadre du colloque en tant que tel.

Pour cette première partie de la journée nous parvenons à passer en revue la proposition de Maged Michael sur les Hazard Pointers et celle de Paul McKenney sur RCU. Dans les deux cas, l'idée est de valider l'interface proposée pour les types impliqués dans la mécanique. Ça prend une bonne heure, mais c'est intéressant et utile.

Meta: Thoughts on generative C++

Herb Sutter présente son puzzle, soit écrire une Case-Insensitive String et réduire le nombre de cas particuliers d'opérateurs à écrire. Par défaut, il faut en écrire 18 pour ce qu'il a demandé. Ceci montre l'intérêt de l'opérateur <=> que Herb Sutter pousse pour C++ 20. Avec l'opérateur <=>, on peut réduire les opérateurs de comparaison à deux ou trois, et ce seraient des méthodes (les versions symétriques seraient générées à partir de ces deux ou trois-là).

Herb Sutter en parle car, même si ce n'est pas le propos ce matin, ça rejoint l'intention de simplifier le langage. Exprimer l'intention de manière plus directe. Réduire le bruit dans le code. Faciliter le débogage. Et nous sommes en C++, donc à coût nul.

Ce matin, Herb Sutter souhaite parler de moyens de rendre le langage à la fois plus puissant et plus simple. Pour l'opérateur <=>, les travaux étaient déjà en cours : le besoin était connu, on cherchait la bonne solution. C'est une approche féconde : partir d'un besoin réel. C'est la même idée pour la métaprogrammation par templates : on le fait, mais on est en droit de chercher des moyens plus agréables d'en arriver aux mêmes résultats. Un autre exemple : les interfaces IDL et autres extensions du même acabit.

Herb Sutter parlera surtout de métaclasses, mais souhaite parler d'abord des fondations : réflexivité, programmation statique, injection. Il remercie Matus Cochlik, Axel Naumann et David Sankel. Il nous avertit que pour aujourd'hui, la syntaxe utilisée est sujette à changement.

Herb Sutter : $expr est une prvalue constexpr de type meta::type. Ça permet de réaliser de la réflexivité sur à peu près tout sauf des énoncés et des expressions.

Exemple :

template <class E> void print_strings() {
   for(auto o : $E.variables()) cout << o.name() << endl;
}

Ceci montre l'intégration harmonieuse du métacode et du code. Comme pour les templates, le code n'est généré que s'il est utilisé.

Herb Sutter remercie ensuite Daveed Vandevoorde, Luis Dionne et Anthony Polukhin pour le code statique. Ensuite, il remercie Gabriel Dos Reis, puis Ville Voutilainen et Faisal Valli pour constexpr, if constexpr, les lambda génériques et les lambda constexpr. On annonce constexpr_vector<T>, les algorithmes constexpr et les allocateurs constexpr. Jason Turner et Ben Deane poussent pour constexpr All The Things.

Herb Sutter présente les blocs constexpr{ ... }, qui ouvrent la porte à de nouveaux petits bonbons.

Herb Sutter : l'opération inverse est d'écrire du code régulier dans un bloc constexpr, avec un opérateur d'injection de code -> { ... }. Par exemple :

template <class E> auto to_string(E value) {
   switch(value) {
      constexpr {
         for(auto o : $E.variables())
            -> { case o.value() : return o.name(); }
      }
   }
}

Herb Sutter dit que la préoccupation est de déboguer et d'entretenir ce genre de code. Nous aurons besoin de bons outils. Cela dit, nous faisons déjà de tels programmes, mais de manière démente. La démarche proposée est intentionnellement Turing-Complete, alors que ce n'était qu'un accident avec le Template Metaprogramming.

Herb Sutter rappelle que les abstraction cachent des choses. C'est délibéré, ce n'est pas un problème. Il faut des outils pour bien accompagner la démarche. Les variables cachent les valeurs; les fonctions cachent le code; les pointeurs cachent les indirections, etc. Les fonctions constexpr cachent les calculs statiques, et if constexpr cache l'exclusion de certains passages. Les modules, les variables constexpr, les métaclasses... toutes cachent des choses. En contrepartie, une bonne abstraction se prête à la conception d'outils.

Herb Sutter en arrive au coeur de son propos : utiliser des métaclasses pour générer du code. Il remercie Andrew Sutton au passage. Il donne aussi des remerciements particuliers à Bjarne Stroustrup pour avoir assuré la cohérence du système de types de C++ à travers les années.

Herb Sutter : les métaclasses permettent de nommer un sous-ensemble de classes partageant un groupe de caractéristiques.Il trace un parallèle avec les fonctions obtenues par une classe dérivée à partir d'une classe de base. Il trace un parallèle avec les choix par défaut de C++ : à ses yeux, les choix par défauts ne sont pas mauvais; le problème est que proposer les mêmes défauts à tout le monde.

Herb Sutter indique que les métaclasses ne visent pas à violer ODR ou à modifier la grammaire du langage.

On peut écrire un truc comme :

 namespace N {

$class interface { ... };

}

interface Dessinable { ... public virtuel quand ça s'y prête ... };

Vu de plus près, Herb Sutter montre l'implémentation de $interface. C'est joli mais je n'ai pas le temps de le noter. Par la suite, il montre les messages d'erreur générés par C# pour une interface et montre qu'on peut faire mieux encore avec sa proposition. Il se bidonne et copie/ colle une interface de C# à C++, et ça compile à un ';' près.

L'exemple suivant est un type value, qui nous donne un tas d'opérateurs gratuitement et assure que, par défaut, on ait des attributs privés et un constructeur par défaut. Il fait une manoeuvre semblable avec std::pair, classe simple mais pour laquelle il y a beaucoup de code à écrire. Il propose de réduire cela à template<class T, class U>literal_value pair{T first; U second;};. Herb Sutter poursuit avec une métaclasse modélisant un enum. Pour celles et ceux qui utilisent des priopriétés en C#, on peut générer pratiquement la même chose (aux parenthèses près). Il montre que dans certains cas, il faut générer des fichiers à la compilation à partir de métadonnées pour supporter des schèmes comme celui de Qt.

Herb Sutter fait un peu de publicité pour le nouveau livre de Daveed Vandevoorde, Nicolai Josuttis et Douglas Gregor. Il y a un exemple de CRTP  à §21.2. Il se trouve que les métaclasses simplifient cette pratique en la rendant moins curieuse.

Herb Sutter : on pense que ça va compiler rapidement, mais ça reste à démontrer. Y aura-t-il des divrgences? Oui, mais on a déjà cette situation (on blague sur les sortes de string).

Herb Sutter rappelle l'importance de l'abstraction, à même le langage et générée par les programmeuses et les programmeurs.

Q : quel est l'impact sur le processus de standardisation?

Herb Sutter : c'est comme pour les classes. On standardisera sans doute les métaclasses les plus communes.

Q : pourra-t-on générer des fonctions globales?

Herb Sutter : oui, il le faudra. C'est un Work In Progress.

Q : et des templates sur des métaclasses?

Herb Sutter : template <class T> property X{ ... };

Herb Sutter mentionne que dans certains cas, par exemple static_assert pour une caractéristique pour une instanciation d'un type générique, il faut injecter du code à propos d'une classe mais hors de la classe. Sa proposition comprend une discussion de tels cas.

Pour la première partie de l'après-midi, les dossier discutés furent inplace_function (Carl Cooke), make_thread() (moi), [[likely]] / [[unlikely]] (Clay Trycha) et fixed_point / elastic_* (John MacFarlane). On parle de deux heures de travail intense.

Poursuite des travaux sur les fixed_point et les entiers élastiques, en particulier pour choisir la meilleure approche lors de divisions entières (rapide mais moins précise; aussi précise que possible mais plus lente).

Ensuite, Alan (dont le nom de famille m'échappe) présente slot_map (un conteneur qui permet une insertion en temps constant et retourne une clé qui permettra des accès en temps constant par la suite). On discute de l'interface de ce type, l'auteur cherchant une forme d'orientation sur six aspects.

Michael Wong et Gordon Brown présente ensuite l'état de la situation pour les systèmes hétérogènes, et introduit les contextes d'exécution pour les ressources et la gestion de l'affinité.

Nous parlons très brièvement d'exceptions dans un contexte d'exécution concurrente. Michael Wong parle d'un error_buffer qui préallouerait la mémoire pour éviter une explosion d'allocations lors de multiples exceptions levées concurremment, et parle de politiques de gestion d'exceptions qui seraient associées aux politiques (std::par par exemple), pas aux algorithmes.

Enfin, Guy Somberg a dit vouloir standardiser std::audio. Certains sont sceptiques, mais il est sympathique et convaincu, alors qui sait?

Boris Kolpackov commence en montrant les lignes download graphics_2d; install graphics_2; import graphics_2d;, comme le suggérait Bjarne Stroustrup. Il utilise bkpg pour montrer comment y arriver. Il utilise des modules, avec import. Ensuite, il suit les mêmes étapes mais en utilisant MSVC.

On a ensuite une présentation d'un spécialiste du monde du High Frequency Trading, où Fast Enough n'existe pas. Sans mesurer, point de vitesse. Il montre un Performance Graph. Par la suite, il parle des coûts des instructions de branchement; même s'ils sont rares, ils peuvent faire mal.

Daniel parle de StaticFlatMap. Pour lui, les outils standards ne suffisent pas. Il montre un extrait lock; for(auto & obj : tab) f(obj) trop lent à cause du lock; il montre un lock, copie la map, unlock, utilise la copie qui est trop lent à cause de la copie. Il montre un remplacement de la map par un vecteur trié (un StaticFlatMap). Il finit par les pour et les contre.

Paul parle d'architecture hétérogène avc OpenCL adjoint à HSA. Je ne sais aps ce que HSA est, mais ça semble être le nom d'une fondation. Les présentations sont limitées à cinq minutes et il ne parvient pas à ficeler sa présentation.

Phil Nash (bien connu, auteur de Catch, travaille chez JetBrains) suit. Il propose un Command Line Parser composable. C'était simple et bien fait.

Gašper propose Copy-Paste All The Things. Son code est... préoccupant. Il fait une utilisation... créative et brisée de noexcept, mais je pense qu'il fait de l'humour volontaire.

Arthur O'Dwyer vient présenter les mentions honorables pour son puzzle. Quelle horreur.

Jens Weller parle de son nouveau processus de certification de bibliothèques.

John MacFarlane vient parler d'entiers signés, pour dissiper les rumeurs négatives (!) à leur sujet.

Siddharth Gupta parle de Features de C++ qu'il dit avoir découvert récemment : case (les goto, c'est le mal), affectation par opérateur ternaire, i[tab], ...

Pee Yong (?) parle d'interfaces et de Vector Support Machines. Elle mentionne Swig pour permettre à C++ de parler avec plusieurs technologies. Sa bibiothèque est shogun.ml (pour Machine Learning).

Victor Kirilov parle de mémoïsation. Il utilise une hashmap pour entreposer les résultats de ses fonctions. Il montre au passage le risque d'avoir des fonctions Stateful. C'est une implémentation perfectible.

Nicolas Fleury parle de Sharpmake. Ça ressemble à CMake et autres, mais ça utilise C# pour fins de scripting et ça gère de gros projets C++. Ils ont une syntaxe pour simplifier la génération de projets sur plusieurs plateformes. Il mentionne http://www.orbitprofiler.com à la fin.

Paul Hampson parle des trigraphes qui disparaissent, puis réapparaissent. Non, Paul; juste non. C'est amusant, cela dit.

Tony Van Eerd propose des C++ Koans. Évidemment, c'est du bonbon.

Runtime Polymorphisme: Back to the Basics

Louis Dionne : présente les cas d'utilisation classiques du polymorphisme au sens de Late Binding. Il mentionne que variant peut faire le travail à l'occasion, mais pas toujours. Il décrit ensuite l'implémentation classique d'une vtbl.

Louis Dionne : le problème de base est que l'héritage est agaçant; on tend à utiliser des pointeurs, ce qui nous prive de la sémantique de valeur qu'omn aime tant en C++. On se trouve aussi à faire typiquement de l'allocation dynamique de mémoire. Enfin, on se ramasse avec une sémantique nullable, et faut gérer le pointé. Évidemment, avec les algorithmes standards, les pointeurs, c'est pas toujours naturel, et l'héritage, c'est intrusif.

Louis Dionne nous recommande une présentation par Sean Parent sur le sujet.

Louis Dionne : ce qu'on veut au fond, c'est une interface (au sens large du terme) qui doit être satisfaite.

Louis Dionne : mon propos est d'essayer d'implémenter cette interface conceptuelle. Il souhaite traiter la politique d'entreposage et la politique d'appeler dynamique indépendamment l'une de l'autre.

Louis Dionne : une approche serait de sortir les états de l'objet, plaçant les pointeurs de fonctions quelque part aussi. Son constructeur de Vehicule<T> (la classe n'est pas générique, le constructeur l'est) initialise vptr_ avec &vtable_for<T>(). Il conserve une vtable sous forme d'un struct contenant des pointeurs de fonction, et un vtable const vtable_for<T> qui est implémenté sous forme d'un variable template et qui applique la technique de void* -> T* de Casio Neri

Louis Dionne utilise dyno::poly<T,politique d'entreposage> pour ses états. Faudra que j'aille voir comment c'est fait.

Louis Dionne son interface utilise decltype(dyno::requires(...)). C'est chargé et la diapo passe vite.

Louis Dionne : faisons-le maintenant avec un Small Buffer Optimization (ce qu'il fait ici est plutôt classique). Je confie à Billy Baker (pas loin) que je sens venir le recours à if constexpr pour choisir entre l'option Small Buffer et l'allocation sur le tas.

Marshall Clow offre une critique de l'implémentation utilisant un bool, recommandant d'utiliser la taille à la place. C'est plus fécond. Louis Dionne dit qu'encoder les actions dans les fonctions est encore plus cool. Marshall Clow fait remarquer que l'option avec un bool peinera à garder la vtbl constante.

Q : est-ce que la vtbl est déallouée?

Louis Dionne : elle est statique, partagée et peut être constexpr

Louis Dionne présente ensuite une option avec entreposage toujours local, qui couvre le pire cas envisagé (static_assert sinon). Le gros irritant est que ça prend de l'espace même pour les petits objets.

Louis Dionne présente ensuite quelques mesures. Il y a un gain net en termes de vitesse avec ses implémentations de type SBO pour des objets de 16 bytes, c'est moins pertinent pour des objets de 4 bytes. Sa recommandation est d'utiliser SBO si c'est possible (caveat : si les membres somnt éparpillés en mémoire, ça ne donne rien).

Louis Dionne passe ensuite pas une forme de Non-Owning Storage avec ce qu'il appelle une Polymorphic View. Une autre possibilité est d'avoir un Shared Remote Storage, où on partage les données mais on fait un Deep Copy avant modification (forme de Copy on Write).

Louis Dionne : maintenant, pourquoi s'en préoccuper? Il parle de std::funtion, inplace_function, function_view, etc. et montre comment on peut toutes les générer à partir d'une même approche. C'est ce qu'il racontait hier chez SG14, d'ailleurs.

Louis Dionne : pour les vtbls, normalement, elles sont distantes. Cela dit, il y a d'autres options. On peut l'inliner dans l'objet (en gardant des pointeurs sur les mêmes fonctions pour les objets d'un même type), mais c'est souvent une pessimisation (en espace, évidemment, mais aussi en vitesse; quelqu'un dans la salle dit que la Cache est en jeu, les vtbls étant moins chaudes).

Louis Dionne : on peut inliner une partie de la vtbl seulement, gardant par exemple le destructeur loin et les fonctions fréquemment appelées proches. Les mesures ne sont pas concluantes. Il examine ensuite le code machine; il dit ne pas être un expert, mais comprendre que la partie distante a deux mov par appel (le vptr et la fonction), et la locale n'a qu'on mov par appel (la fonction) une fois le premier mov de vptr fait.

Louis Dionne : parlant d'inlining, il montre un exemple avec Static Dispatch (rapide), Dynamic Dispatch local et Dynamic Dispatch dynamique (lents). En permettant l'inlining du Dynamic Dispatch (local), il devient aussi rapide que le Static Dispatch. C'est un truc à retenir, peut-être pour SG14. Quelqu'un dans la salle pense que le gain de vitesse est un artéfact d'un autre phénomène cependant, alors faudra investiguer et réanalyser.

Louis Dionne : tout ça est lourd et complexe. Avec la réflexivité statique, il devient possible d'extraire une interface d'un type, puis de générer le pont par injection de code sans rédiger de Boilerplate outre le métacode.

Q : on peut donc remplacer l'héritage par de l'effacement de type?

Louis Dionne : oui. Il y a plusieurs moyens d'y arriver.

Q : côté vitesse, il y a une grosse différence entre appeler une méthode virtuelle sur un objet et l'appeler sur plusieurs objets en séquence. La taille joue aussi sur la Cache. Aussi, entreposer la vtbl à distance ne compte pas nécessairement beaucoup car il y a normalement peu de types distincts pour le nombre d'objets, alors la vtbl isolée sauve de l'espace et réduit les Cache Misses.

Louis Dionne : oui, faut mesurer.

Q : as-tu un équivalent d'override?

Louis Dionne : je n'ai pas d'héritage du tout.

Q : j'aime le design pour les fonctions (une interface, plusieurs politiques). On fait quelque chose de semblable avec les string pour SSO. Est-il raisonnable d'exposer ça au code client? On peut envisager vector avec SBO, mais ça influencerait la sémantique des itérateurs...

Louis Dionne : vrai, ça mérite réflexion.

Q : les compilateurs modernes sont parfois capables de dévirtualiser des appels de fonction, ce qui influence la vitesse d'exécution.

Q : et si on utilise des concepts?

Louis Dionne : (je n'entends pas la réponse; on est à la pause et il y a beaucoup de mouvement)

Qt as a C++ Framework: History, Present State and Future

Lars Knoll : je suis ravi de parler de Qt en tant que cadriciel pour C++.

Lars Knoll demande aux gens de signaler s'ils connaissent Qt et l'ont déjà utilisé. Beaucoup de mains se lèvent; il semble content.

Lars Knoll : Qt est le cadriciel le plus complet à ma connaissance pour C++. Sous licence duale (commercial, [L]GPLv3), livré à code ouvert, disponible sur des tas de plateformes mobiles ou pas.

Lars Knoll présente un graphique mettant en relief ce que Qt supporte, c'est-à-dire beaucoup de trucs. Un autre graphique montre Qt for Device Creation, utilisé pour les systèmes embarqués. Il mentionne au passage un débogueur à distance. Suit une présentation de Qt Creator, un IDE multiplateforme. Il a un petit glitch technique, malheureusement.

Lars Knoll : revenons 26 ans dans le passé, en Norvège, où deux étudiants d'univerisité en 1990-1991 devaient développer une interface personne / machine pour Linux et Mac. C'était frustrant, et ils ont convenu du besoin d'un système orienté objet pour réaliser leur tâche. Leur souhait était de faire en sorte que ce soit agréable et facile. Ils ont conservé le design original (essentiellement dessiné sur une Napkin), qu'il nous présente. La lettre Q était « disponible », et le QObject central à leur design existe encore aujourd'hui. On voit aussi la première version de leur site Web (ouf...). Intialement, toutes leurs ventes étaient en ligne. La première vente portait le numéro 211 pour ne pas donner l'impression que la compagnie n'avait jamais vendu quoi que ce soit.

Lars Knoll : la version 1.0 de Qt est sortie en 1996. Sur Linux en code ouvert, et sur Windows 95. Ils n'avaient pas de budget de marketing et ont compté sur la communauté Open Source. Quelqu'un a écrit un courriel pour mousser le produit qu'il aimait beaucoup, et ça a explosé. Un an plus tard, KDE arrivait sur le marché; fait avec Qt, cela a donné une solide impulsion au cadriciel.

Lars Knoll : la version 2.0 est sortie en 1999. La compagnie est passée de cinq employés à cinquante, et la licence GPL a été adoptée. Le code généré par leur éditeur était un peu monolithique, et demandait de recompiler souvent, alors ils ont conçu Qt Designer.

Lars Knoll : Qt 3 est arrivé en 2001. Les templates prenaient plus de place. Qt 4 est arrivé en 2005 avec une mise à jour importante du code (plus de généricité, moins de pointeurs, donc moins de gestion de mémoire pénible). La déclinaison sur Windows était désormais à code ouvert.

Lars Knoll : nous avons ensuite été achetés par Nokia. Ils ont mis beaucoup d'argent, et nous sommes passés à une licence LGPL. Plusieurs suggéraient d'abandonner l'IDE et de passer à Visual Studio ou Eclipse, mais avec le financement de Nokia, ils ont plutôt créé Qt Creator. Malheureusement, en 2011, le PDG de Nokia les a informés qu'ils étaient largués et il a fallu s'en remettre. Ils ont quitté Nokia en 2012.

Lars Knoll : Qt 5 est ensuite arrivé. Le volet multiplateforme n'était pas au point. Nous avions aussi des interfaces trop statiques, et les gens voulaient voir des animations. Qt est devenu complètement Open Source (avant, le développement était interne, et les sources étaient exposées une fois le produit publié).

Lars Knoll : aujourd'hui, Qt Company comprend 250 employés, les revenus sont de l'ordre de 32 M €, et on trouve environ un million d'usagers.

Lars Knoll : les objectifs sont Empower the Users, Freedom and Independence, Open Source, Cross-Platform. La majorité des Commits viennent de l'intérieur de la compagnie, mais plusieurs autres compagnies contribuent (BlackBerry participait beaucoup). L'offre est horizontale. Le code est construit pour être facile à lire : un concept par classe, un concept par méthode, nommage rigoureux, sémantiques claires, similitudes dans les pratiques pour donner un impression d'homogénéité, etc. Leur objectif est de couvrir d'office 90% des cas d'utilisation, et de rendre les derniers 10% possibles.

Lars Knoll : nous ne respectons pas rigoureusement le You don't Pay for what You don't Use. Par contre, nous veillons à ne pas compliquer notre API inutilement. Des API de bas niveau sont rendues disponibles pour les chemins critiques.

Lars Knoll : on vise une barrière à l'entrée relativement basse, donc on vise les débutant(e)s et les intermédiaires. On a aussi remarqué que le code tend à vivre longtemps... Pour cette raison, nos API sont très stables. Côté nommage, nous évitons les abréviations. Côté API, nous évitons les paramètres obscurs (en particulier, les bool pour choisir un comportement parmi deux). L'API utilise beaucoup des propriétés, qu'il considère intuitives. Il présente au passage du code de QSlider avec Qt 3, puis avec Qt 4 et Qt 5. J'ai des réserves pour l'avant (difficile à comprendre)... et pour l'après (lent). Il leur reste du travail à faire.

Lars Knoll : les classes dérivent de QObject. Le design repose sur des pointeurs, utilise des propriétés, des signals / slots, et de l'introspection dynamique. La suppression d'un noeud parent provoque la suppression e ses enfants, et il n'y a pas de cycles. Les signals / slots sont type-safe, thread-safe et fonctionnent entre deux threads. La génération de code est allégée par un recours à des macros. Ça fonctionne avec des λ.

Lars Knoll : Qt utilise le moc (Meta Object Compiler). Ça génère des métadonnées pour fins introspectives, ce qui permet d'examiner les représentations textuelles des enum et permet de repérer des propriétés par leur nom. La colle des signals / slots est générée de cette manière aussi. (je fais remarquer à Billy Baker que Lars Knoll ne code probablement pas souvent ces jours-ci; il utilise constexpr d'une manière illégale dans ses diapos).

Lars Knoll : pour utiliser les nouvelles répétitives for, nous avons dû écrire des adaptateurs car (a) nos objets sont manipulés indirectement, (b) les objets d'un conteneur peuvent se détacher dynamiquement, et (c) il y a des différences sémantiques entre nos objets, plus anciens, et les types dont le standard fait la promotion.

Lars Knoll : nos types couvrent des trous de la bibliothèque standard. Nous supportons Unicode, les fuseaux horaires, du graphique, des atomiques pré-2011, etc.

Lars Knoll : nous créons les interfaces personne / machine de manière déclarative, mais le code sous-jacent est impératif. Le langage déclaratif est QML, où les objets sont des QObject. Ce langage facilite la mise en place de propriétés, et facilite les liens avec JavaScript. QML représente le volet visible de l'interface personne / machine avec une syntaxe minimale. C'est un langage Designer-Friendly, mais qui s'intègre aisément avec C++, et qui facilite les liens entre les deux (lie un rappel à un événement).

Lars Knoll : Qt Quick Designer est un éditeur récent et plutôt joli.

Lars Knoll : nous en sommes à Qt 5.9, mais Qt 5.10 est en Feature Freeze et sort officiellement en novembre 2017. Nous visons Qt 5.12 pour novembre 2018; nous visons une mise à jour tous les six mois. Nous supportons plusieurs API de bas niveau dont DirectX et OpenGL, et avons quelques endroits où OpenGL est un peu trop exposé.

Lars Knoll : côté améliorations et raffinements, nous travaillons à réduire la consommation de ressources, mieux s'intégrer avec la voix et la réalité virtuelle, et offrir de meilleurs outils graphiques à nos usagers.

Lars Knoll : côté C++, nous utilisons C++ 14 et C++ 17, mais nous sommes limités par une dépendance envers Visual Studio 2013. Nous attendons avec impatience C++ 20 avec les concepts et (idéalement) les modules. La réflexivité statique nous aidera énormément. Pour nous, exposer des macros à la frontière des modules est une nécessité.

Q : qu'en est-il de la sécurité de Qt?

Lars Knoll : nous essayons de faire en sorte que (j'ai manqué un bout)

Q : dit-on Q-T ou « cute »?

Lars Knoll : en Europe, on dit « cute »

Q : j'utilise Qt tous les jours mais il y a des dépendances dont je me passerais...

Lars Knoll : explique comment faciliter la migration, et pourquoi il estime que leurs classes sont meilleures que celles du standard dans certains cas.

The Asynchronous C++ Parallel Programming Model

Hartmut Kaiser : mon plan avec cette présentation est d'avoir un accroissement de vitesse linéaire avec le nombre de coeurs à ma disposition.

Hartmut Kaiser : actuellement, les outils à notre disposition sont disparates et ne composent pas bien. Mêler OpenMP et MPI ou CUDA est difficile, par exemple. Il montre un schéma composite qui permet de voir les fortes variations en qualité d'utilisation de coeurs sur une machine très bien fournie sur le plan matériel.

Hartmut Kaiser présente sommairement la loi d'Amdahl. Il a une belle illustration : paralléliser 50% du code trace une limite rigide de gain de vitesse à deux fois la vitesse de la version séquentielle, dans le meilleur cas, même avec 1'000'000 de coeurs.

Règle #1 : il faut paralléliser le plus possible

 Hartmut Kaiser présente ensuite les quatre cavaliers de l'apocalypse : la famine (Starvation), donc des coeurs sous-alimentés; la latence (Latency), limitée par la vitesse de la lumière; la charge administrative (Overhead), donc le temps qu'on passe à gérer le parallélisme; et l'attente (Waiting) de la résolution des situations de contention, et qui inclut le faux partage. S-L-O-W donc

Hartmut Kaiser : on a aussi des problèmes en lien direct avec les modèles de programmation. OpenMP insère une barrière en fin de boucle. MPI insère une barrière à chaque tic de communication.

Hartmut Kaiser : on a aussi des problèmes en lien avec l'abus de synchronisation. Par exemple, des exécutions inter-noeud en Lock-Step dans MPI. On insère parfois de la synchronisation dont l'algorithme n'a pas vraiment besoin.

Hartmut Kaiser : on a aussi des problèmes en lien avec une coordination insuffisante entre le parallélisme sur et hor d'un noeud.

Hartmut Kaiser : enfin, on a des ennuis avec les variations de modèles d'une technologie à l'autre.

Hartmut Kaiser : et les algorithmes parallèles de C++ 17? Ils sont simples, fonctionnent, mais sont fondamentalement Fork-Join et introduisent un point de rendez-vous bloquant. Chaque réduction, en fait, heurte le parallélisme potentiel. Il y a un dessin à faire ici pour mes cours de parallélisme.

Règle #2 : choisir un environnement qui embrasse S-L-O-W

Hartmut Kaiser : par exemple, faites travailler le CPU pendant que le GPU fait des calculs avec CUDA.

Hartmut Kaiser : pour réduire le facteur O, il y a lieu de lancer énormément de threads avec de petites unités de traitement à réaliser. En théorie du mois; en pratique, ça ne fonctionnera pas. Des charges de 10'000 threads, ça introduit plein de problèmes mécaniques, et ça complique le raisonnement.

Règle #3 : permettre une granularité de traitement variable.

Règle #4 : sursaturez les threads, puis balancez la charge de manière adaptative.

Hartmut Kaiser : le défi est de trouver comment paralléliser pleinement nos programmes, et d'exposer l'asynchronicité sans exposer la concurrence. Faites en sorte que les dépendances de données soient explicites. Cachez les concepts de thread ou de communication. Enfin, développez des mécanismes plus féconds.

Hartmut Kaiser : raisonnez par appels de fonctions et passage de messages. Les futures représenteront des dépendances de données. Ça fait le travail. Voyez la machine comme une seule machine abstraite de C++, avec une seule grosse mémoire.

Hartmut Kaiser : je ferai de la futurisation pour transformer le code séquentiel en code auto-parallélisé. Notre API sera respectueuse du standard.

Hartmut Kaiser : explique ensuite ce qu'est une future. C'est un beau modèle pour découpler un producteur d'un consommateur, et il cache les threads. En fait, les futurs transforment la concurrence en parllélisme.

Hartmut Kaiser aborde ensuite le parallélisme récursif. Il promet de ne pas calculer Fibonacci; il traverse plutôt un arbre en collectant les valeurs qui y logent puis en réalisant un calcul sur ces valeurs. Son premier exemple comprend un wait_all() et est donc une variante de Fork / Join. La futurisation nous aide : la traversée peut retourner une future, construite par une combinaison de calculs asynchrone (il utilise .then()).

Hartmut Kaiser montre ensuite comment y arriver avec des coroutines. C'est encore plus joli, presque du code séquentiel en surface, mais pleinement parallélisé.

Hartmut Kaiser aborde ensuite la question de la communication asynchrone. Il mentionne Go et ses canaux pour communiquer d'une goroutine à l'autre. On peut s'en inspirer mais mettre des futures aux extrémités.

Hartmut Kaiser : recommande ensuite de pousser pour de l'asynchronicité partout, incluant au tout début en débutant par f = make_ready_future<T>() puis, dans une boucle, faire f = f.then([]{ ... });. Le reste communique par des canaux asynchrones.

Hartmut Kaiser : par voie de futurisation, on obtient un débit maximal sur la seule base des dépendances de données, sans avoir besoin de synchronisation.

Les diapos se terminent par une courte table pour guider le processus de futurisation, et par une publicité (brève, merci!) pour HPX. Son dernier exemple est une simulation de la fusion de deux naines blanches.

Naked coroutines live (with networking)

Gor Nishanov : les principes de design sont (a) échelonnabilité, (b) efficacité, (c) interaction avec les autres facilités à coût nul, (d) une mécanique ouverte, et (e) utilisable même en l'absence d'exceptions.

Gor Nishanov trace un historique des coroutines. Il montre ensuite des petits extraits du texte normatif, et montre avec enthousiasme le code C++ 20 (on l'espère) correspondant. Il rappelle sa démo à coût nul de l'an passé.

Gor Nishanov : Toronto 2017 nous donne (au moins) deux cadeaux, soit la TS des coroutines et la TS du Networking. Il fait la liste de certains des bonbons de std::networking (il y en a plein, j'ai hâte!), et insiste sur io_context. Un petit exemple de minuterie répartie est présenté (quelques lignes)

Gor Nishanov : il montre ensuite un serveur TCP (beaucoup de code). Ensuite, dans les coroutines, on a trois mots clés et quatre outils. On se bidonne.

Gor Nishanov donne ensuite dans le live coding :

• Pas le droit de faire co_return sur main()
• Il inclut <future> et <experimental/coroutines>
• Il fait using std::experimental;
• La coroutines TS ne donne pas de sémantique particulière aux coroutines. C'est un squelette. Il montre donc comment écrire coroutines_traits, puis y va pas à pas en ajoutant chaque morceau duquel le compilateur se plaint.
• Il faut entre autres écrire unhandled_exception() car les exceptions ne peuvent pas fuir des coroutines.

Gor Nishanov se met ensuite à implémenter une fonction pour initier une coroutine, d'abord de manière « simple », puis de manière plus complexe. Son exemple naïf transfère 75 MB/s. Ce sera le Baseline du test. Il le fait aussi avec boost::future et boost::coroutine, ce qui est chouette. Avec coroutines, le code fond...  mais initialement, on tombe à 41 MB/s. Gor Nishanov nous explique qu'il y a des coûts inhérents au recours à std::future; entre autres, on ne veut pas que les rappels du networking TS se fassent dans un .then() pour éviter de causer un débordement de pile.

On passe à la manière « difficile ». Il ajoute un awaitable. Son premier jet s'arrête à 61 MB/s. On rit un peu. Il sort son backup préparé d'avance. On gosse, et on finit par s'apercevoir que c'est le premier test qui était farfelu; en pratique, il est plus lent que 60 MB/s.

Son serveur final tient sur une page recto.

Gor Nishanov présente ensuite des complications. Son exemple fait tick tock en co-boucle. Après le premier tick, il appelle cancel() et ça fonctionne. Ce qui suit est intéressant, mais se digèrera mieux doucement (beaucoup de petits changements ici et là).

Gor Nishanov revient ensuite sur ses coroutines à coût nul de 2016. Il soulève la question d'un éventuel transfert de contrôle synchrone, d'une consultation des paramètres d'une promesse, de la découverte d'allocateurs, etc.

Ce qu'il faut retenir, c'est que pour le moment, on a les meilleurs résultats avec la manière la plus difficile. Il reste donc un peu de polissage à faire avant C++ 20.

Q : peut-on sérialiser les états d'une coroutine?

Gor Nishanov : peu probable

Q : comment gères-tu les errerus?

Gor Nishanov : avec des error_code et std::expected (donne un exemple).

Q : dans la façon facile, pourquoi suspend_never est-il retourné par final_suspend()?

(j'ai manqué la réponse)

C++ 17 Parallel Algorithms

Dietmar Kühl : je ne parlerai pas de comment les implémenter, mais bien de comment les utiliser.

Dietmar Kühl : il y a beaucoup de concurrence à notre disposition. Le nombre de coeurs croît, on peut envisager le GPU, les FPGA, le CPU évidemment...

Dietmar Kühl : de prime abord, C++ est séquentiel. Les cas non-triviaux sont difficiles à détecter par un compilateur.

Dietmar Kühl donne un exemple d'une boucle de type transform(b,e,b,f) écrite manuellement. Il indique que ça peut se paralléliser si l'opération f() n'a pas d'effet de bord.

Dietmar Kühl montre un exemple manuel, mais avec OpenMP, et montre les limites de cette approche (je dis essentiellement la même chose dans mes cours).

Dietmar Kühl montre un exemple manuel utilisant std::thread. Ça fonctionne, mais on est dans le détail non-essentiel et c'est difficile à bien calibrer. Il fait la même chose avec std::async(), puis avec tbb::parallel_for(), mais ça se ressemble.

Dietmar Kühl passe ensuite à transform() avec une politique d'exécution parallèle. Ça suppose que les appels concurrents à l'opération se compléteront, et ne provoqueront pas de Data Race. Ça suppose aussi que les paramètres soient copiés, pas déplacés.

Dietmar Kühl : le statu quo est que les algorithmes fonctionnent, et sont séquentiels par défaut. Appliquer une politique comme premier paramètre permet de paramétrer les ajustements de comportement.

Dietmar Kühl : il y a des irritants : plusieurs n'utilisent pas les algorithmes. Les petits répétitives seront plus rapides en séquentiel. Il faut aussi être prudents avec les itérateurs et les opérations qui pourraient introduire des Data Races si nous sommes imprudents.

Dietmar Kühl : passer une politique permet la concurrence, sans l'obliger. Le type de politique décrit ce qui est permis. Les accès aux éléments sont faits dans le respect de ces règles. L'implémentation peut appliquer la politique, mais n'y est pas contrainte (elle peut tout faire de manière séquentielle).

Dietmar Kühl présente les politiques d'exécution (seq, par, par_unseq). Le modèle pourra être étendu dans le futur, entre autres pour profiter des exécuteurs. Un trait std::is_execution_policy<T>::value permet de valider le rôle de T.

Dietmar Kühl : le rôle de std::execution::seq est de permettre le débogage et la généricité. Intéressant de savoir qu'une exception, par conformité avec les autres politiques, provoquera un appel à std::terminate(). Les input_iterator ne sont pas nécessairement supportés, et les types de retour des algorithmes peuvent différer de ceux des algorithmes séquentiels sans politique d'exécution.

Dietmar Kühl : le rôle de std::execution::par est de permettre une exécution parallèle sur plusieurs threads. Les acès aux éléments ne doivent pas entraîne de Data Races

Dietmar Kühl : le rôle de std::execution::par_unseq est de permettre une exécution parallèle entrelâcée, comme avec des registres SIMD ou sur un GPU. Les verrous sont interdits.

Dietmar Kühl : on supporte tous les algorithmes pour lesquels il existe une implémentation raisonnable. Certains noms sont différents pour les versions parallèles et séquentielles. La majorité est supportée, mais Dietmar Kühl fait le tour de ceux qui sont exclus (ceux sublinéaires, ceux étranges, ceux où il y a du chevauchement, ceux qui vont partout en même temps). Étrangement, generate() et generate_n() sont supportés mais iota() ne l'est pas. Ça ressemble à un oubli. Dietmar Kühl fait aussi remarquer que le chevauchement est interdit pour copy() mais pas pour copy_n(), un autre oubli.

Dietmar Kühl fait remarquer que pour la famille des find(), il se peut que nous préférions les versions séquentielles.

Dietmar Kühl : pour la gamme des opérations de type reduce, les opérations doivent être associatives.

Dietmar Kühl : les fonctions inclusive_scan() (version parallèle de partial_sum()) et exclusive_scan() servent surtout à implémenter d'autres algorithmes. Il se trouve que l'ordre des paramètres est différent pour ces deux algorithmes.

Dietmar Kühl : les fonctions transform_reduce(), transform_inclusive_scan() et transform_exclusive_scan() servent surtout à fusionner des résultats.

Dietmar Kühl : ça vient avec C++ 17 mais c'est pas pleinement implémenté, en particulier par_unseq. La plupart des implémentations exigent des itérateurs random_access. HPX semble pas mal pour x86.

Q : peut-on contrôler le nombre de threads utilisés?

Dietmar Kühl : éventuellement peut-être, avec les exécuteurs.

Dietmar Kühl poursuit avec des mesures sur plusieurs machines. Il compare l'iusage de maps avec for_each(), thread, async(), tbb, etc. Sur une machin avec une quantité insuffisante de coeurs, c'est lent. Un autre test proposé avec une charge plus signifiante, et ça paraît mieux. Un algorithme comme sort() est aussi testé, puis accumulate().

Dietmar Kühl : sans surprises, les algos parallèles seront terriblement lents si la charge est petite.

Dietmar Kühl : recommandations : (a) utilisez les itérateurs de type random_access, (b) (trop vite!)

Dietmar Kühl donne un aperçu du proche futur (plus de politiques, une intégration avec les exécuteurs, continuations, contrôle des blocs). Il parle d'une éventuelle exécution std::constant pour imposer constexpr. Il est satisfait dans l'ensemble : bien utilisé, ça donne des résultats

Q : en tant qu'appelant, comment puis-je éviter des exceptions?

Dietmar Kühl : les algos n'en lèvent pas; c'est les types qui le font.

C++ Exceptions and Stack Unwinding

David Watson : voici quelques Unwinders, surtout pour Linux (il connaît moins Windows) : lubunwind, llvw-libunwind, libgcc

David Watson : à l'horaire, les exceptions à coût zéro, les diverses ABI, et le Unwind info (dwarf, elf, le système d'exploitation)

David Watson : Itanium n'est pas qu'une architecture, c'est aussi (beaucoup) une ABI pour l'exception handling

David Watson : par Zero-cost exceptions, on prétend que ne pas lever d'exceptions ne coûte rien

Exemple avec code d'erreur, code généré sur x86_64

Exemple avec try catch (catch(...)), coût zéro à l'oeil... mais c'est une illusion, le compilateur a mis le code de gestion d'exception dans la fonction appelante

Exemple avec try et deux blocs catch, pas de code machine présenté

Exemple avec une fonction qui se limite à throw 1;. On voit dans le code machine une fonction pour allouer l'exception, et le code pour la lancer

__cxa_begin_catch et __cxa_end_catch. Les exceptions sont reference-counted

__cxa_allocate_exception et __cxa_throw. La première est essentiellement un appel à malloc(). Pour bad_alloc, il y a une allocation a priori qui est faite

Le véritable enjeu est __cxa_throw

Itanium ABI

__cxa_throw appelle Unwind_RaiseException

Une fonction de « personnalité » __cxx_personality_v0 navigue une table pour trouver le bon bloc catch (Unwind_Get/SetIP pour le pointeur d'instruction, Unwind_Get/SetGP pour les registres généraux)

David Watson présente ensuite les fonctions de [llvm-]libunwind, qui diffèrent de celels de libgcc

David Watson : implémentons un Two-Phase Unwinding en C++. Étape A : recherche du bloc. Il commence par reculer d'une étape sur la pile cas il ne veut pas tenir compte de la fonction qui analyse la pile. Étape B : unwinding. Quand on trouve le bloc catch, la pile demeure valide, et on peut reprendre l'exécution au point du throw. De même, C++ a accès à la pile entière dans terminate() pour générer de meilleurs diagnostics.

noexcept et terminate() : on lève une exception d'un thread. On remarque que gcc triche en insérant un catch(...) silencieux pour interopérer avec pthread, alors ceci brise le code de navigation de la pile. David Watson s'en sort en insérant un noexcept.

Sans exceptions, sous POSIX, on a setjmp() et longjmp(), alors qu'avec GNU C, on a backtrace(), mais ce dernier est moins bon pour C++ car il ne tient pas compte des destructeurs.

David Watson examine entre dwarf (le Debug Info), qu'il obtient avec readelf --debug-dump=frames binaire

David Watson : on n'a pas à récupérer tous les registres pour s'en sortir. Les Caller-Saved s'arrangeront tout seuls dans les blocs catch; on doit s'occuper des Callee-Saved et des Frame-Related.

David Watson parle ensuite de cas vécus de débogage. L'un d'eux était :

void b() {

   char foo[1] __attribute((aligned(32))); 

}

... qui générait du code dénué de sens.

David Watson : le Stack Unwinding de dwarf est Turing-Complete

David Watson : un problème est que des sections du binaire peuvent être réparties dans plusieurs bibliothèques. C'est plus compliqué s'il s'agit de .so. Le problème clé est le recours à DLOPEN et DLCLOSE, car fermer puis ouvrir recyclera le même espace mémoire alors les nouvelles infos peuvent écraser les anciennes.

David Watson : les fonctions dlopen, dlclose, dl_iterate_phr consomment un verrou.

David Watson : le Unwind Info passe par une table de hashage.

David Watson montre comment générer un Stack Trace.

David Watson propose un court exposé pour améliorer la vitesse de backtrace() (problème de cache trop petite; problème de contention sur un verrou)

David Watson recommande quand utiliser les exceptions, mais il passe très vite et je manque de temps pour prendre des notes...

Q : y a-t-il des implications de sécurité?

David Watson : c'est pas mon domaine

Q : est-ce que les exceptions utilisent RTTI?

David Watson : nécessairement un peu, pour comparer les id de types

Q : a-t-on une investigation pour se débarrasser du malloc()

David Watson : pas à ce que je sache

Q : peut-on utiliser ces bibliothèques pour autre chose que des levées d'exception?

David Watson : pour les backtraces, c'est assez ouvert

Q : what is the WCET? With memory allocation, it seems unbounded

David Watson : in production, the worst case I've seen stemmed from lock contention with multithreaded programs

Designing a Unified Interface for Execution

Gordon Brown commence par présenter CodePlay, son employeur, et lui-même. Il nous annonce d'office que ce qui est présenté est inachevé et vise une version éventuelle de C++.

Gordon Brown présentera sont travail dans le contexte des exécuteurs. Il commence par expliquer ce qu'ils sont, et pour ce faire il montre brièvement les divers moteurs à la OpenMP ou future::then qui existent déjà. Les exécuteurs se veulent une unification standardisée de ces divers modèles.

Gordon Brown : les exécuteurs cheminent depuis 2012 (il présente les principales propositions). Depuis Oulu 2016, un sous-groupe travaille strictement sur ce sujet. Les plus récents sont p0443r2 et p0761r0. Selon lui, SG1 est sur le point de former un Executors TS.

Gordon Brown : qu'est-ce qu'une exécution? Ça dépend à qui on pose la question, et la réponse dépendra du point de vue (parallèle, concurrent, réseau, hétérogène, etc.)

Gordon Brown : comment desservir tout ces gens avec une interface unifiée? Il faut trouver un point commun. Ici, c'est l'exécution d'un appelable. Il nous faut donc une topologie commune d'exécution.

Gordon Brown : un flux d'instructions est un appelable prêt à être exécuté.

Gordon Brown : un agent d'exécution léger exécute un flux d'instructions

Gordon Brown : une fonction d'exécution combine les deux

Gordon Brown : un exécuteur est une interface pour combiner tout ça

Gordon Brown : une ressource d'exécution est l'abstraction du matériel

Gordon Brown : un contexte d'exécution gère des agents d'exécution légers

{

   execution_context execCtx;

    auto exec = execCtx.executor()

   exec.execute([&] { func(); }); 

}

Gordon Brown : il faut ensuite établir les différentes bifurcations d'exécution. L'un des enjeux est la cardinalité (un ou plusieurs threads). Un autre est la directionnalité (existe-t-il un canal pour synchroniser, et retourner une future, ou lever une exception?). Ceci peut être unidirectionnel ou bidirectionnel. Enfin, il y a les garanties de blocage (peut-être, toujours, jamais) d'un thread lorsque l'exécution se complète.

Gordon Brown : il faut maintenant définir les fonctions d'exécution (execute(), twoway_execute(), bulk_execute() et bulk_twoway_execute()). La raison pour plusieurs déclinaisons tient à des différences de signature et de sémantique. Il donne des exemples de chacune. Le single-one-way est essentiellement une fomnctio, le two-way est essentiellement une future, le bulk ressemble à TBB et le bulk two-way est comme TBB mais retourne plusieurs résultats

Gordon Brown : pour établir les propriétés de l'exécution (les quatres du paragraphe précédent, qui impactent la signature, et les trois options de blocage). Plusieurs autres propriétés sont présentées : mise en correspondance avec un thread, garanties d'exécution de masse, garanties de Forward Progress, continuation, alimentation future en travail, allocateur.

Gordon Brown : pour ce qui est de personnaliser les exécuteurs, trois points de personnalisation sont offerts, et chacun accepte des propriétés en paramètre : Require (retourne un exécuteur), Prefer  (retourne un exécuteur) et Query  (retourne un valeur).

Q : how does Prefer work?

Gordon Brown : Prefer tries to Require, but returns the original executor if it fails

Gordon Brown présente un exemple des droits pour une exécution dont la complétion serait non-bloquante.

Gordon Brown : un exécuteur polymorphique peut retourner un exécuteur statique ou un exécuteur dynamique. Il donne un exemple pour justifier cela.

Q : quelles fonctions un exécuteur polymorphique doit-il supporter?

Gordon Brown : il doit exposer l'interface entière, mais peut lever des exceptions pour indiquer une opération non-supportée

Q : que se passe-t-il si une future vit plus longtemps que son exécuteur?

Gordon Brown : il faut un contexte d'exécution qui perdure

Gordon Brown présente ensuite l'implémentation d'un exécuteur, un two-way qui accepte une fonction F && f, en fait une promesse, puis une future, et fait essentiellement comme async(). Il utilise ensuite cet exécuteur pour implémenter std::async() mais en lui passant un Executor comme premiere paramètre (require twoway never_blocking), puis en créant la future par twoway_execute()

Gordon Brown montre comment calculer une factorielle en parallèle sur plusieurs substrats (CPU, GPU et autres) avec ces mécanismes.

Gordon Brown : pour le futur, quelques trucs.

Gordon Brown : à propos des execution_context et execution_resource, il donne un exemple pour créer un static_thread_pool

Gordon Brown : la séparation en quatre (twoway, bulk, etc.) est un mensone. Il y en a six, et les deux autres sont then_execute() et buik_then_execute() pour enchaîner des continuations.

Q : .then() pour le Concurrency TS et .then_execute() ici, relation?

Michael Wong : ce ne sont pas les mêmes futures.

Gordon Brown : on vise à renommer Require / Prefer pour éviter les conflits de noms avec les concepts. On débat de noms (c'est controversé)...

Q : sur un exécuteur polymorphique, en quoi Prefer et Require diffèrent-ils?

Gordon Brown explique, mais la nuance est mince.

Gordon Brown : les back channels sont one-way, never_blocking (du Fire and Forget) mais peuvent servir lors d'une levée d'exception (à l'oeil, le code semble en partie réflexif)

Q : peut-on enrober un one-way dans un two-way?

Gordon Brown : on le souhaite encore.

Q : il y a des exécuteurs dans le networking TS aussi. Seront-ils fusionnés?

Gordon Brown : ils sont impliqués dans le projet

Q : quel est le lien avec les coroutines?

Gordon Brown : à clarifier

Q : le flux d'exécution peut-il être envoyé sur plusieurs unités d'exécution? Le compilateur peut-il savoir en vertu de quel substrat il doit compiler une fonction?

Gordon Brown : ça se fait

Q : peut-on spécifier ou consulter une telle restriction?

Gordon Brown : oui. Une des propriétés est le Thread Mapping, qui permet de savoir si on est sur le CPU ou pas.

Q : comment faites-vous l'effacement du code pour nourrir le GPU?

Gordon Brown : c'est pas trivial. Faut des exécuteurs statiques.

Going Nowhere Faster

Chandler Carruth : je ne vous montrerai pas comment aller plus vite cette fois, mais je vais m'intéresser au code qui ne va nulle part... mais vite.

Chandler Carruth : je vais à la fois couvrir les erreurs les plus communes et les plus étranges dans une répétitive.

Chandler Carruth se présente. À date, ses présentations du passé :

• Utiliser des algos, structures de données et des idiomes efficaces
• Mesurez et comprenez pourquoi vous avez les chiffres que vous avez
• Utilisez des structures de données hybrides pour maximiser l'impact de la Cache

Chandler Carruth : si vous n'avez pas de benchmark pour votre code, c'est que la vitesse de votre code ne vous intéresse pas

Chandler Carruth : donc, vous avez une boucle dans votre benchmark qui prend du jus... C'est probablement la faute des données. Envisagez des outils (profileur, Efficiency Sanitizer)

Chandler Carruth : essayons de mesurer avec des Performance Counters

Chandler Carruth montre une fonction nommée cacheBench() qui attaque des tailles (exprimées en bytes) très spécifiques, toutes des puissances de deux. Un vecteur de nombres aléatoires, et un vecteur d'indices dans le premier vecteur, puis faire une somme de valeurs en ordre de ces indices (donc deux Access Patterns dont un des deux saute partout, dans le but de rendre la Cache très triste). Ça modélise ce qui se passe avec map ou unordered_map

Chandler Carruth exécute le tout, et essaie de faire sortir des valeurs instructives. Avec 8Ko, ça va bien (en termes de quantité de données traitées par seconde), puis 16Ko, puis 32Ko... À 64Ko, ça ralentit, puis ça dégénère par la suite. Il se trouve que son processeur (AMD Epic mais avec une Cache L1 de 64Ko justement). À 8Mo, la vitesse s'écroule totalement. En fait, le seuil de destruction est précisément la taille de la Cache L3 : la plus grosse chute, c'est quand on n'est plus en Cache du tout.

Chandler Carruth utilise perf stat pour tirer plus d'informations de ses tests. Cool, ça affiche les Cache Misses par niveau de Cache, pour les dcache et les icache!

Chandler Carruth : maintenant, examinons une Tight Loop. Il montre une boucle qui fait des clamp(). Il regarde le code machine et voit arriver un cmovge dans le code machine qui semble pensé pour faire clamp() justement. Il remplace le cmovge par un branchement. Il demande si ce sera plus vite; dans la salle, quelqu'um fait remarquer que ça dépendra des données sur lesquelles on opère (ici, ce sont des valeurs entre 0 et INT_MAX). On spécule sur l'impact du Branch Prediction. Chandler Carruth fait remarquer que les processeurs contemporains ne font pas de prédiction si l'étiquette est dans le futur. Surprise : le cmovge est plus rapide... alors qu'il ne l'était pas ce matin durant sa répétition :) On l'applaudit et on se bidonne, mais c'est le péril du Live Coding. Chandler Carruth se souvient qu'il a laissé un truc pas rapport, et on constate que le branchement, dans ce cas, est plus rapide que l'instruction cmovge sophistiquée (qu'il s'est battu pour faire générer par l'optimiseur!)

Chandler Carruth : les processeurs contemporains sont fortement spéculatifs. Il montre une boucle qui réalise un Dot Product des valeurs de deux vecteurs. Il montre le code machine généré. Cependant, les instructions x86 ne sont pas ce qui est exécuté; c'est plutôt des micro-opérations qui seront exécutées. Et il se trouve qu'il y a des macro-op-fusions dans les processeurs qui sont en pratique plus grosses que les opérations d'origine. Chandler Carruth montre que la condition de la répétition de la boucle est hautement probable, par définition, donc on peut poursuivre l'exécution et sortir quand elle ne s'avère pas. Le processeur utilise un Reordered Buffer qui accumule plusieurs cycles d'exécution de la boucle, puis fait ce qu'on nomme du Register Renaming. Ici, le processeur les renomme tous, et ajoute de parallélisme dans la boucle pour réaliser une exécution spéculative de plusieurs itérations d'un seul bloc.

Conséquence : la latence pour le premier résultat était huit cycles, mais pour le deuxième résultat, on n'a eu besoin que de deux cycles. Il y a un Stall Cycle à la sixième itération car certaines opérations n'étaient pas complétées... On a donc six instructions parallèles. En pratique, le cmovge est différent en ceci que son résultat ne peut être spéculé, il doit être calculé.

Chandler Carruth : des outils pourraient-ils nous aider? Oui, le Intel Architecture Code Analyzer génère un graphe très lisible.

Chandler Carruth : les écriture régulières en mémoire nous coûtent cher. Ça introduit des Stalls.

Q : as-tu vu une différence sur Intel?

Chandler Carruth : rien de majeur. Ils se ressemblent beaucoup

Q : que penses-tu de [[likely]] et [[unlikely]]?

Chandler Carruth : je les aime, mais ça tend à mal vieillir. J'aimerais un outil qui profile un binaire et guide les attentes

Q : dans ton code machine, comparer avec un littéral semblait plus rapide que comparer avec la valeur d'un registre...?

Chandler Carruth : oui, je sais, mais je ne sais pas ce qui se passe

Q : la boucle de la fin est plus rapide mais a plus de Stalls...?

Chandler Carruth : le Store Buffer cumule plusieurs écritures. x86 offre des garanties d'ordonnancement

Q : dans quels cas, dans une boucle, est-il raisonnable d'utiliser cmovge?

Chandler Carruth : quand les dépendances seront nécessairement déjà connues

Unbolting the Compiler's Lid: What Has My Compiler Done for Me lately?

Matt Godbolt réalise un tirage à l'intérieur de Compiler Explorer, à l'aide d'un générateur de nombres pseudoaléatoires écrit par Jason Turner.

Matt Godbolt : mon nom est devenu un verbe, et je ne m'y attendais pas.

Matt Godbolt présente son historique personnel. Il faisait beaucoup d'assembleur pour le plaisir et la vitesse, a passé dix ans à faire des jeux, puis a écrit des outils pour traiter des sources C++. Maintenant, il donne dans le code à basse latence.

Matt Godbolt : mes objectifs incluent rendre l'assembleur moins apeurant, et vous faire apprécier votre compilateur. Il nous donnera un historique de Compiler EXplorer, un survol d'assembleur, un petit laïus sur ce que le compilateur fait pour nous, et un regard dans les coulisses du Compiler Explorer.

Matt Godbolt : je fais du High Frequency Trading. On ne peut pas adopter de nouveaux mécanismes du langage sans les mesurer. Il utilisera au passage quick-bench.com (qui repose sur Google Benchmark) pour la démo, mais recommande de mesurer, de ne pas présumer.

Matt Godbolt décrit le fonctionnement de l'assembleur x86, sous la forme Intel et comme une sorte de pseudo C. Il explique pourquoi un xor edx,ex peut être préférable à un mov edx,0 (ça prend moins de bytes dans le code machine)

Matt Godbolt montre le fonctionnement de la version 0.1, qui était un outil console (une combinaison de scripts et de petits outils à la ligne de commande, vraiment). Il explique les raisons de son passage au Web.

Matt Godbolt montre ensuite comment fonctionne Compiler Explorer, et comment il associe les lignes des sources avec les lignes du code généré. Il montre aussi une diff view (que je ne connaissais pas; c'est génial!). Constat : un for sur des intervalles ne coûte rien, accumulate non plus (du moins sur des entiers).

Matt Godbolt compare ensuite du code pour faire une multiplication avec une constante, en particulier une puissance de deux (ça utilise lea, qui est un shift), puis avec un nombre suspect (ça utilise un imul). Il écrit une fonction hyper spécialisée... et le compilateur faire le imul avec la constante d'origine, défaisant la non-optimisation naïve.

Matt Godbolt approche ensuite la question de la division. C'est lent (22-29 cycles) et il n'y a qu'un seul diviseur dans l'ALU. Il montre que les divisions par des puissances de deux se transforment en shifts. Par contre, avec d'autres constantes, ça introduit des trucs étranges... car le compilateur construit une simplification hyper efficace (au lieu de diviser par trois, il multiple par deux tiers et fais un shift). Pour le modulo, il discute de quelques cas d'utilisation (p. ex. : trouver une case dans une hash map).

Matt Godbolt montre ensuite un exemple pour compter les bits allumés dans un entier. Il constate une instruction blsr (qu'il ne connaissait pas avant de préparer sa présentation), mais avec un petit changement le compilateur constate que popcnt (qui fait précisément cela) est utilisé. Un peu fou!

Matt Godbolt montre ensuite $\Sigma_{i=1}^n(i)$, et clang utilise une variante de l'algorithme de Gauss soit $\frac{x(x+1)}{2}$, en évitant une approche naïve qui aurait pu causer un débordement. Il parle un peu de dévirtualisation et d'autres manoeuvres appropriées pour le code OO.

Matt Godbolt passe en coulisses. Son Back-End est écrit avec Node.js et s'exécute sur l'infrastructure d'Amazon (EC2). Il utilise une Edge Cache, un équilibreur de charge, des machines virtuelles contenant des images Docker, et un espace partagé pour entreposage des compilateurs. Les compilateurs sont construits dans des images Docket, entreposés sur S3. Il utilise les compilateurs à code ouvert, et passe par Wine pour les compilateurs de Microsoft car il est moins confortable pour administrer Windows (mais Andrew Pardoe dit que Microsoft va l'aider).

Matt Godbolt dit que les compilateurs sont d'immenses vecteurs d'attaque, et qu'il faut penser au pire (d'où les images Docker). Avec LD_PRELOAD, il y a moyen de faire crasher le compilateur, charger un fichier d'extension du disque, et prendre le contrôle de la machine.

Matt Godbolt : pour le Front-End, j'utiliser Microsoft Monaco (utilisé pour Visual Studio Code) avec GoldenLayout. Le code est sur GitHub.

Matt Godbolt : Jason Turner montrera dans un prochain C++ Weekly comment exécuter une instance de Compiler Explorer localement.

Matt Godbolt : j'ajouterai sous peu CFG viewer (Control Flow Graph), Unified Languages (pour comparer trans-langages; pour le moment, ce sont tous des sites distincts) et la capacité d'exécuter du code.

Q : dans la manoeuvre gaussienne, le compilateur utilise 33 bits pour éviter un débordement

Matt Godbolt : wow, merci!

Q : as-tu un outil pour raccourci les liens?

Matt Godbolt : je n'entrepose rien pour le moment; tout est dans l'URL, et j'utilise un URL Shortener de Google. Un jour peut-être (je ne veux pas être imputable)

Q : envisages-tu supporter le code du noyau de Linux?

Matt Godbolt : prends le compilateur que tu veux (donne un truc pour les includes)

Q : ça coûte combien?

Matt Godbolt : approximativement 200$ par mois, mais mon Patreon me donne environ 300$ par mois alors je suis Ok.

Q : peut-on supporter le LLVM IR?

Matt Godbolt : oui (c'est déjà là), simple question d'options de compilation

Q : il y a un émulateur x86 en JavaScript (donne le nom)

Matt Godbolt : cool!

Building for the Best of Us: Design and Development with Kids in Mind

Sara J. Chipps commence par tester la salle pour voir qui a appris à programmer avant l'âge de 20 ans. Presque tous.

Sara J. Chipps : quand j'ai lancé mon entreprise, je voulais enseigner aux femmes adultes, puis j'ai étudié la démographie pour faire le constat que le groupe le plus puissant au mond est... les filles de 9 à 14 ans. C'est elles qui découvrent les nouvelles technologies et les transforment en succès (Instagram et autres, même si c'est illégal à cet âge). Pourtant, elles sont peu nombreuses dans les technologies

Sara J. Chipps : les jouets de gars sont plus cool, plus stimulants. On leur envoie un message. Chez les filles, c'est beaucoup moins intéressant, et il n'y a presque rien entre 9 et 14 ans. J'ai consulté 200 jeunes filles pour mieux les comprendre, puis je leur ai fait des bracelents qui s'adaptaient à leur vêtements. Elles m'ont dit « c'est con, je ne porterai jamais ça ».

Sara J. Chipps : j'ai visé l'amitié, c'est très important à cet âge. Une communauté en ligne, on peut envoyer des messages secrets à nos amies (plusieurs designs, plusieurs formats... Il n'y a pas deux poignets pareils à cet âge!).

Sara J. Chipps : j'ai fait un prototype Looks Like, et un prototype Works Like, puis on a fusionné les deux. Des douzaines de designs. Les clientes ont choisi les fleurs.

Sara J. Chipps fait une démo. Elle fait de Michael Caisse son ami. Il y a un geste à faire pour devenir des amis. Ils choisissent une couleur. Leurs bracelets changent quand ils sont proches l'un de l'autre. Avec le même bracelet, elle se fait une autre amie, avec une autre couleur.

Sara J. Chipps laisse sa place à une jeune utilisatrice de JewelBots, Sumeya. Sumeya explique qu'on programme un JewelBots avec C++ sur Arduino. Les composants sont des LED, des minuteries, des animations, des buzzers et des boutons. Elle présente un Pomodoro Timer qu'elle a programmé elle-même. La fonction setup() est un Run Once, la fonction loop() est le corps du programme. La minuterie du JewelBots est en milliseconde. Sumeya cause une erreur délibérément pour nous montrer comment ça fonctionne. Sumeya parle ensuite de la communauté, et du plaisir de programmer avec son papa (Andrew Lumsdaine). Elle dit avoir codé un jeu avec une amie. Sumeya parle ensuitte de la communauté et des forums pour échanger avec es ami(e)s. Il y a un JewelBots Magazine. Elle nous présente aussi son blogue. Elle recommande d'utiliser le mot-clic #codelikeagirl

Eleanor, amie de Sumeya, prend le relais. Sa présentation commence par une animation. Elle se présente comme un ambassadrice de JewelBots, soit une utilisatrice qui répand la bonne nouvelle. Elle vante le fait que JewelBots s'adresse aux filles, et passe par l'amitié pour créer un réseau. Il y a deux plateaux Arduino pour coder : le plateau solo, et le plateau d'amitié. Le plateau solo est celui qui a été présenté par Sumeya. Le plateau d'amitié s'exécute quand les ami(e)s sont proches. On vise les enfants de huit ans et plus.

Sara J. Chipps : côté design et choix technologiques, voici comment nous avons procédé :

• Les bracelets sont un mélange de plastique et de nylon
• Il y a un bouton à l'intérieur, un port USB, quatre LED RGB, une puce ARM M0 Cortex 32 bits, 256Ko/128Ko flash + 32Ko/16Ko RAM
• Elle nous donne les specs sous la couverture (trop long pour noter)
• Ça peut connecter à un téléphone intelligent, un drone, etc.
• La mise en paires passe par BLE
• (Sara J. Chipps fait un ping à Michael Caisse)
• C'est facile à configurer, et ça utilise Cordova / Ionic

Sara J. Chipps explique comment la communication fonctionne. Elle utilise C++ pour que ça fonctionne sur son mini matériel

Sara J. Chipps nous montre la couche système, qui n'est pas ce qui est exposé aux enfants. L'API qui est exposée est pensée spécifiquement pour les flos : les noms ont des sons qui parlent aux flos, et des paramètres qui correspondent à la réalité concrète qui doit être exprimée.

Sara J. Chipps : pour les LED, ils avaient le choix entre diverses métaphores; ils ont choisi la rose des vents, mais Sara J. Chipps pense que c'était pas le bon choix. Ça arrive

Sara J. Chipps explique le pont entre le code de bas niveau, écrit par des adultes, et l'API exposée aux flos (du code OO, ça peut donner des API très accessibles)

Sara J. Chipps explique que le Arduino a un défaut : c'est long d'y téléverser une mise à jour

Sara J. Chipps : on a un taux de conversion usagers -> programmeuses de 44%, et presque 10'000 unités vendues. Il y a eu 4'400 programmeuses dans les premiers mois, et elles tiennent des hackathons réguliers. Le projet est à code ouvert (sur GitHub). Les enfants se codent des jeux (c'est amusant pour jouer à la cachette!)

Q : travaillez-vous sur de nouveaux modèles?

Sara J. Chipps : on a constaté qu'un accéléromètre pourrait être un plus.

Q : avez-vous envisagé un chargeur sans fil?

Sara J. Chipps : on a pris un fil pour le moment, mais on y songe. Une charge pleine peut durer deux jours si on s'en sert beaucoup

Q : avez-vous de la documentation multilingue

Sara J. Chipps : pas encore

Q : puis-je m'en imprimer un en 3D?

Sara J. Chipps : les specs sont à code ouvert

Q : ça coûte combien?

Sara J. Chipps : donne les prix. Moins de 100$, moins cher si on en prend 2-3.

Q : distance?

Sara J. Chipps : 30 mètres

Q : Apple seulement?

Sara J. Chipps : Android bientôt