À propos de cppcon 2016

Quelques raccourcis :

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

Merci spécial à Félix-Antoine Ouellet pour avoir signalé des coquilles et aidé à compléter un terme que je n'avais pas eu le temps de prendre en note.

Ce qui suit est une sorte de journal de voyage, avec éléments humains et éléments techniques.

Glossaire

Quelques termes que vous verrez ci-dessous :

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

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

Début du contenu technique

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

Fin du contenu technique

Jour -3 16 septembre 2016

Note : ce jour a été écrit un peu comme une liste de trucs que je ne veux pas oublier; je repasserai dessus quand je serai moins pressé pour le transformer en texte lisible par des humain(e)s.

J'ai fait mes bagages à peu près, tôt le matin. Je tends à voyager léger, mais cette fois j'ai besoin d'une valise car je serai absent une semaine entière. Pendant qu'elles dormaient, je suis passé faire un câlin à Vayda et embrasser Za. Ensuite, j'ai amené Ludo (un Power Ranger ce matin) à la garderie, et j'ai pris soin d'informer les éducatrices de mon absence, juste au cas où il réagirait.

Étant donné que ma classe des deux prochains jours n'est pas prête (surprise, me direz-vous), je me suis adonné à sa préparation avant d'aller offrir ma prestation cours au Collège. Bavarder avec Vincent Echelard.

Cours avec mes brillants et sympathiques étudiants de 420-KHJ-LG.

Retour vers la maison. Embrasser la belle Vayda et Za, mon amoureuse, à la clinique vétérinaire.

Préparer les derniers trucs, embarquer avec Réal, mon chic papa qui a accepté gracieusement de m'amener à l'aéroport. Arrêt bref pour nourrir des chats, puis aéroport.

Douanes, fouillé à cause de mes cheveux, trop opaques.

Travail, travail. Entend que mon vol a changé de porte. Me lève, vais prendre un peu d'argent américain au bureau de change (taux de 1,44... Ouch!). Il m'en a coûté 223 CAD pour avoir 150 USD!

Situation plus grave de prévue : retard de deux heures pour cause de réparations sur notre avion. Je devais n'avoir qu'une heure pour transiter entre les avions à Vancouver, donc je vais manquer mon vol... Pas cool.

Plusieurs sont dans le pétrin. Les dames d'Air Canada sont gentilles, mais l'une d'elles me dit que je n'ai aucune chance de me rendre à temps à Seattle pour samedi matin, que j'y serai au mieux samedi après-midi. Pas bon : près de 80 personnes m'attendent samedi àh, et elles ont payé cher pour être là. Dans les mots de la dame, « le comptoir aux miracles est fermé ». Je déprime et je commence à chercher un « plan B », même si la dame m'affirme qu'il n'y a aucun vol vers Seattle qui ne soit déjà plein, même en ne passant pas par Vancouver. Heureusement, sa collègue est plus créative et me concocte un trajet de Vancouver vers Seattle àh du matin, arrivée àh 55, ce qui me fait passer la nuit dans le terminal d'aéroport (où je prépare ma prestation) mais m'amènera à destination avant que le cours ne commence. Je pourrai même peut-être prendre une douche, qui sait? J'écris à Jon Kalb, qui organise l'événement, pour l'avertir de ce qui se passe; lui et Bryce Adelstein-Lelbach m'aident en me suggérant des trucs pour réduire les irritants en chemin; ils me trouvent un moyen de transport (le sympathique bénévole Mitch Carlson me cueillera à l'aéroport) pour passer plus rapidement de l'aéroport à l'hôtel demain, et font le nécessaire pour que je puisse accéder à ma chambre rapidement malgré le fait que j'arriverai avec un jour de retard.

Courriel du chic Gabriel Aubut-Lussier, qui sera au colloque cette semaine. Je crois comprendre qu'il devait prendre le même vol que moi et vit un irritant semblable. Étant moins pressé que moi, il dormira à Montréal ce soir et ne partira que demain.

L'avion quitte Montréal vers 18 h 50. C'est un avion distinct de celui prévu à l'origine, et qui vient d'arriver de Calgary. L'hôtesse qui nous accueille est extraordinaire : elle blague, rassure les gens et a appris nos noms pendant le deux heures d'attente, ce qui fait qu'elle nous accueille de manière personnalisée avant même de voir nos passeports... Wow! Nous recevons des coupons échangeables pour 10$ de nourriture dans un aéroport de notre choix au Canada.

En avion, j'aime bien regarder la carte du trajet pendant que nous volons; malheureusement, cet avion ne présente pas de carte fonctionnelle pour le trajet (imprévu) que nous faisons alors l'écran n'est que plate. J'écoute La soirée est encore jeune en baladodiffusion pour me divertir (j'entends d'ailleurs que mon ancien étudiant Andy Emond a gagné des billets dans un concours pour assister à l'émission; bravo!), puis du Patrick Watson qui me berce alors que je sommeille un peu. Peu avant de débarquer de l'avion, je bavarde un peu avec mon chic voisin de siège, un pompier de Sherbrooke qui s'en va faire du vélo à Vancouver et à Whistler.

À Vancouver, je parle un peu au téléphone avec mon amoureuse Za. Il est minuit à la maison. Je me trouve un endroit pour grignoter : petit resto vietnamien, soupe Pho très piquante, qui me coûte justement 10$... et cinq sous. J'utilise mon coupon de nourriture et j'assume la différence de cinq sous  . C'est très bien comme repas. Ensuite, trouver une prise de courant de travailler sur mon cours de samedi et de dimanche. Le fait que je puisse travailler sans prise de courant est dû au chic Claude Cardinal du CeFTI, qui a eu la gentillesse de remplacer la pile de mon ordinateur portable qui n'avait plus d'autonomie depuis quelques années. Merci, cher ami!

Le reste de la nuit est passé à travailler sur la présentation de demain.

Jour -2 17 septembre 2016

Étant donné que je n'ai pas dormi, la distinction entre hier et aujourd'hui est difficile à faire (où tracer la ligne?), mais disons que la journée débute avec l'ouverture des guichets d'Alaska Airlines, versh 30, moment où je suis passé de « préparer des trucs » à « m'assurer de me rendre à destination, avec mes bagages ».

Les gens d'Alaska Airlines ont été très gentils, et tout s'est déroulé rondement. Le passage aux douanes fut long. Dans mon expérience (ça fait... quatre fois, je pense, que je transite pas ici au cours des dernières années et c'est souvent long; pas démesurément, mais on se trouve dans une file qui n'avance pas beaucoup, même s'il y a plusieurs allées pour fouiller les gens. Je ne sais pas ce qui fait que la logistique semble plus lourde ici, mais faut toujours prévoir plus d'une heure pour ce passage.

L'attente post-douanes a duré environ une heure, ce qui n'est pas mal, et le trajet en avion a été court (moins de 40 minutes de vol). J'ai perdu le fil, m'étant endormi, mais il pleuvait beaucoup dehors alors je n'ai rien manqué du paysage.

Mitch Carlson, un bénévole de CppCon, est venu me cueillir à l'aéroport. Tout s'est très bien passé; il faut prendre un petit train à Seattle pour passer d'un terminal à l'autre, et la collecte de bagages est centralisée au pavillon principal. Ma valise est arrivée en même temps que moi, et Mitch Carlson est arrivé quelques minutes plus tard. Un individu absolument charmant, futur papa, souriant et content de participer à l'événement. Il m'a amené à l'hôtel (je réside au Hyatt Regency, gracieuseté des organisateurs du colloque), où j'ai pu prendre une douche rapide et me changer pour partir vers le lieu du colloque (arrivé à l'hôtel versh 45, parti vers le colloque versh). La distance entre les deux est courte, une quinzaine de minutes de marche, mais il pleuvait beaucoup et nous étions très pressés. En arrivant, j'ai pu serrer la main rapidement à Anthony Williams, ce dont je suis content car je recommande souvent son livre et ses manoeuvres à mes étudiant(e)s.

La salle où j'ai donné ma prestation est grande et étalée à l'horizontale, avec de grands écrans à derrière moi à gauche et à droite. Les gens en avant au centre voient plus ou moins les écrans, et les gens au fond à gauce et à droite me verraient mal en temps normal mais je suis un peu surélevé alors c'est pas si mal. On m'a donné un micro portatif mais les participant(e)s et moi avons convenu qu'avec les fluctuations de voix que je fais quand j'enseigne, ce serait dangereux pour les oreilles des gens dans les locaux avoisinants. Nous avons convenu de ne pas l'utiliser, du moins tant que ma voix tiendra la route. J'ai mis du matériel à la disposition des gens alors celles et ceux qui voient moins bien les écrans peuvent suivre quand même sur leur ordinateur portatif. La salle a une capacité de 100 personnes et nous sommes près de cela (près de 90, en fait, mais là-dessus il y a des bénévoles, qui peuvent assister pour beaucoup moins cher – 100 USD – en récompense pour leur travail, alors que les autres paient plus de 1000 USD pour l'occasion). Il y a environ 8-10% de femmes dans la salle, ce qui est peu mais mieux que lors des années précédentes, alors je prends ça comme quelque chose de positif, et elles participent beaucoup. Côté provenance régionale et communautés culturelles, c'est extrêmement varié, et là aussi ça participe beaucoup.

Cette année, CppCon offre plusieurs classes de maîtres; la liste est disponible sur http://cppcon.org/classes/ donc vous pouvez aussi voir la mienne. J'ai une classe pas mal pleine, et je suis content car les autres formateurs (en particulier Anthony Williams, mais aussi Dan Saks, Michael Caisse et Giuseppe D'Angelo) sont tous des vedettes dans notre petit milieu.

Je ne suis pas aussi bien organisé que je ne l'aurait souhaité, dû aux circonstances, mais je pense que les gens ont aimé; mon style un peu particulier sur scène n'a pas nui. C'est une grosse journée, les pauses sont courtes (le dîner se fait sur 45 minutes) et on s'efforce de respecter les délais à la lettre, car les autres classes vivent les mêmes contraintes que nous et la gestion de la nourriture, en particulier peut être complexe avec autant de gens. Parlant de nourriture, nous avons été très bien traités : il y avait du choix, c'était bon, et il y avait de quoi accommoder les restrictions alimentaires de toutes et de tous. Le café est fourni par Starbucks, Seattle oblige, et on n'a pas à attendre quand les cruches se vident, le personnel étant très efficace.

Ce dont j'ai l'air dans ces moments-là (photo saisie par Bryce Adelstein-Lelbach)

J'ai ajusté les détails comme répéter les questions à haute voix et ajuster ma gestion d'une classe très horizontale à la première pause (les gens m'ont donné la rétroaction dont j'avais besoin pour faire les petits ajustements qui permettent que tout aille bien, signe que la confiance s'est installée) et un irritant technique dû à mon ordinateur portable, qui fait que je n'arrivais pas à programmer efficacement avec eux (nous ne parvenions pas à faire répéter correctement le contenu de mon écran sur les écrans géants, alors je devais projeter seulement sur les écrans géants et faire des acrobaties) a été réglé par l'ajout d'un écran près de moi pour me permettre de voir ce que je fais. L'équipe technique a été avenante et efficace.

À la fin de la journée, les participant(e)s avaient un souper non loin, où j'était invité, mais je n'avais plus de carburant. J'ai pris les dernières questions, Mitch Carlson a eu la gentillesse de m'amener à l'épicerie pour que je m'achète un rasoir jetable et de la crème à raser (j'ai bêtement oublié les miens à la maison), j'en ai profité pour acheter une bière locale que j'ai dégusté à ma chambre d'hôtel. J'ai parlé à ma belle Za par Skype, retourné quelques courriels, constaté des mots de certain(e)s participant(e)s qui ont vu des coquilles dans les diapos (j'adore quand les gens me le disent; ça m'aide tellement) et m'ont dit avoir aimé leur journée, puis je me suis couché vers 19 h 45 heure locale, complètement à plat.

Jour -1 18 septembre 2016

Je me suis levé tôt ce matin, après avoir dormi longtemps, et j'ai travaillé sur ma présentation de la journée. Je ne suis évidemment pas arrivé à tout ficeler comme je l'aurais voulu, mais je savais que je tiendrais la route pour la journée 

La douche du matin m'a fait un grand bien. Le rasage aussi, ne serait-ce que pour avoir l'impression de redevenir humain. Je passe régulièrement quelques jours sans me raser, faute de temps, mais la barbe de cette fin de semaine avait des relents de nuit passée debout dans un aéroport et j'avais bien hâte de passer à autre chose.

Pas eu le temps de déjeuner, mais nous avons droit à un goûter le matin. Comme hier, nous avions ce matin plusieurs sortes de bagels et plusieurs garnitures possibles, et ce fut bien bon. Il m'a fallu attendre à la pause avant de manger, alors je commençais à avoir faim (mon enseignement est assez physique : je bouge beaucoup et je parle fort, et je compte beaucoup sur ma présence sur scène pour tenir les gens sur le bout de leur siège; je tends à être moins efficace en fin de séance, surtout lors de longues journées comme hier et aujourd'hui).

Je dirais que mon cours était bon mais décousu. Je dois aller à Amsterdam plus tard cet automne pour redonner le même genre de formation, et je sais comment je vais resserrer le tout.

Bon dîner, aussi, mais j'ai eu beaucoup de questions et je n'ai pas réussi à goûter au dessert. Je n'ai pas non plus réussi à prendre de collation ou de café en après-midi. Cela dit, il me semble que c'est un signe que les gens étaient intéressés.

Après mon cours, j'ai eu droit à une bonne demie-heure de questions du public. Ils ont fini par quitter pour aller manger, et je suis resté dans la salle vide pour parler à mon amoureuse Za qui me manque énormément déjà (sur ce plan, la semaine sera longue...). À un certain point, les gens de l'entretien ici sont entrés pour transformer l'endroit de salle de classe à salle de conférence, enlevant les tables et tout le tralala, ce qui a un peu mis fin à notre bref moment d'intimité à distance.

Quelques trucs amusants constatés aujourd'hui, car dans une classe de maîtres, le formateur apprend aussi. D'abord, ceci est incorrect :

template <class T>
    void f(int n) {
       T *p = reinterpret_cast<T*>(new unsigned char[n * sizeof(T)]);
       int m = 0;
       try {
          for(auto q = p; q != p + n; ++q, ++m)
             new (static_cast<void*>(q)) T{};
       } catch(...) {
          for(auto qq = p; qq != p + m; ++qq)
             qq->~T();
          throw;
       }
       // ...
       delete [] p; // <-- ICI
    }

... car bien que p soit alors de la bonne taille et bien qu'il contienne techniquement des T à ce stade, donc les bons destructeurs seront appelés pour les bons objets, il se trouve que les implémentation associent typiquement l'information aux tableaux à libérer dynamiquement de manière telle que de ne pas appliquer delete[] sur le type alloué peut mener à du comportement indéfini.

Aussi, l'exemple suivant donnait des résultats inattendus sur gcc et clang, qui profitent du fait que le code soit techniquement du comportement indéfini (il contient des Data Races) :

enum { N = 1'000'000 };
int n{};
thread th0 { [&n] {
   for(int i = 0; i < N; ++i) ++n;
} };
thread th1 { [&n] {
   for(int i = 0; i < N; ++i) ++n;
} };
th0.join(); th1.join();
cout << n << endl;

Techniquement, ce code devrait donner moins de 2'000'000 (beaucoup moins, en fait), mais sur ces compilateurs, avec optimisation, les compilateurs constatent que le code est brisé et écrivent simplement 2'000'000 dans n sans le calculer, à titre d'optimisation.

Faute de temps, je ne suis pas allé souper, mais nous avons une réception ce soir pour accueillir les gens. Je ne compte pas rester tard (je suis fatigué et j'ai des trucs à préparer pour ma conférence de mardi matin) mais je vais en profiter pour manger une bouchée. Je vais aussi pouvoir revoir des gens sympathiques que je ne vois que dans ces occasions, ce qui est bien en soi.

Quand les gens commençaient à arriver et quand les tables commençaient à se déplacer, j'ai eu la visite du toujours très gentil Walter E. Brown, qui est venu me serrer la main. Après avoir parlé un peu avec lui, je suis allé me mettre en ligne pour cueillir mon badge, les billets donnant droit à une consommation gratuite, et j'ai mangé quelques bouchées en bavardant avec des gens qui sont maintenant de ceux que je recroise avec plaisir : le chic Guy Davidson, qui vient de se marier; quelques gens de boîtes de jeu vidéo de Montréal (on nous reconnaît à notre accent); Billy Baker; John McFarlane; JF Bastien; Brittany Friedman (autrefois Brett Friedman), à qui le nouveau look va très bien et qui semblait aller magnifiquement bien; Chandler Carruth, très chic, Michael Caisse, qui vient aussi de donner deux jours de cours et qui semblait aussi un peu fatigué; Bryce Adelstein-Lelbach, qui semblait soulagé que tout se soit bien passé; Jason Turner, qui parlait avec Jens Weller; etc. J'étais pas mal fatigué, cela dit, alors après à peu près une heure, j'ai salué les gens et je suis parti vers l'hôtel. En sortant, j'ai eu le plaisir de croiser Gabriel Aubut-Lussier et Kevin Cadieux, deux de mes anciens étudiants qui font leur propre chemin depuis longtemps, ce qui m'a permis de leur souhaiter la bienvenue.

Cela dit, je suis fatigué alors dodo, car le colloque commence demain.

Jour 0 19 septembre 2016

Premier jour du colloque. Debout àh 50 du matin (pas mal mon rythme sur la côte Ouest), j'ai eu la chance d'échanger un peu avec Za avant qu'elle ne quitte pour le boulot.

Par les échos provenant d'Internet, j'apprends que plusieurs des gens qui, comme moi, ont participé au financement du dernier album de Marillion, groupe que j'adore, ont reçu leur copie de cet album. J'aurai peut-être le plaisir d'écouter le mien à mon retour à la maison samedi, une raison de plus (comme si j'en manquais!) d'avoir hâte de revenir parmi les miennes et les miens. C'est toujours étrange, ces voyages : c'est prenant, rude physiquement et intellectuellement, très stimulant et enrichissant, et je suis content d'être là, de contribuer à la communauté et d'apprendre avec les meillleur(e)s, mais ça me remet toujours au visage à quel point j'aime ma femme et mes enfants.

J'apprends aussi que Close to Paradise, de Patrick Watson, a dix ans cette semaine. Ouf, comme si on avait besoin d'un autre coup de vieux! 

Mon plan aujourd'hui est de participer au colloque, bien sûr, mais aussi de préparer ma présentation de demain matin, qui n'est pas encore ficelée comme devrait l'être une présentation d'une heure filmée pour la postérité (en fait, elle ne l'est vraiment pas!).

Cette année, la tradition de nommer les salles de l'événement de manière thématique se poursuit. Après avoir utilisé les noms de femmes importantes dans l'histoire des sciences l'an dernier, nous rendons cette année hommage à quelques-uns des géants musicaux qui nous ont quitté en 2016, année particulièrement rude sur ce plan. Il a fallu faire des choix déchirants, bien sûr. Je serai aujourd'hui au Bowie Hall en début de journée (c'est la grande salle qui nous accueille tous ensemble... Nous sommes plus de 900 cette année, c'est un très gros événement), puis aux salles Vanity (chanteuse pop près de Prince), Kantner (de Jefferson Starship, groupe aux multiples noms) deux fois, et Frey (des Eagles). Le problème avec CppCon est que l'offre est colossale (il y a sept « tracks » concurrentes, donc il est très rare que l'on ne souhaite pas être à au moins deux endroits en même temps); heureusement, tout (ou presque) est filmé et publié sur YouTube en format de haute qualité. Aujourd'hui, je suis déchiré entre aller voir Lisa Lippincott, dame extrêmement pertinente qui proposera une réflexion en profondeur sur « l'interface de base » des objets, et Arthur O'Dwyer qui est très pertinent, amusant et qui a eu la gentillesse de venir participer à ma classe des deux derniers jours. Je penche vers Lisa Lippincott, parce que ça recoupe l'enseignement de l'informatique, mais je sais que je vais manquer quelque chose en n'allant pas à la rencontre d'Arthur O'Dwyer.

Truc particulier : j'ai participé à la préparation de puzzles pour amuser les participant(e)s cette semaine (les deux autres qui en ont fait sont Jason Turner et Herb Sutter). Le mien est un truc sans prétention en trois étapes, qui parle de pirates (c'est Talk Like A Pirate Day aujourd'hui, après tout!) et sera publié ce matin; celui de Jason Turner est un truc qui a un lien avec sa présentation de mercredi matin, et celui de Herb Sutter est un truc qui a un lien avec sa présentation de vendredi matin (pour en savoir plus sur le sien, qui est particulièrement intéressant, voir https://herbsutter.com/2016/09/17/a-little-puzzle-for-cppcon/). J'espère que mon petit truc va divertir les gens, car c'est vraiment sans prétention.

J'ai informé le chic Matt Godbolt que j'ai utilisé son précieux Compiler Explorer en classe pour démontrer certains faits avec les participant(e)s ces derniers jours. Il semblait ravi! Il m'a envoyé un lien vers la version bêta de la prochaine version de cet outil pour que je puisse jouer avec... C'est un beau cadeau, car l'outil en question est diablement utile.

Sur le chemin vers le Meydenbauer Center (le lieu qui accueille l'événement), je pensais écouter un peu de musique en marchant (l'air est frais, il a plu un peu plus tôt ce matin, c'est agréable), mais j'ai croisé plusieurs personnes qui étaient dans ma classe ou qui en avaient entendu parler, alors j'ai bavardé un peu. Arrivé sur les lieux un peu avanth (heure locale). Je me suis trouvé une table sur une mezzanine pour préparer un peu mieux ma présentation de demain. D'autres font de même ici et là (Guy Davidson, tres chic aujourd'hui, et Sean Middleditch sont à l'oeuvre non-loin de moi car ils présentent ce matin; ils semblent bien s'amuser).

J'ai eu droit à une remarque tout à fait justifiée d'un sympathique participant au cours de la fin de semaine, Vaugh Kato, à l'effet que j'ai insuffisamment couvert les aspects du sujet annoncé portant sur les entrées / sorties. C'est un truc que je dois pallier dans mon matériel d'ici la fin de la semaine, et que je dois ajuster d'ici ma conférence à Amsterdam.

Je suis ensuite descendu au sous-sol, vers le Bowie Hall, pour cueillir mon chandail officiel de l'événement (ça fait deux ans que l'on parle d'en offrir aux participants, alors c'est fait!). Le mien est de couleur Golden, alors je présume que certain(e)s seront ravi(e)s de me voir occasionnellement porter un chandail non-noir.

Ce qui est différent pour moi en 2016, et je l'ai aussi remarqué à Oulu, est que je fais un peu plus partie de la communauté. Un peu comme hier, où la socialisation était facile et naturelle (beaucoup plus que lors de CppCon 2014, où peu de gens étaient habitués à une opération de cette envergure), ce matin, Walter E. Brown et Marshall Clow bavardaient et ont pris le temps de me saluer; je me servais un café quand Herb Sutter est passé me dire bonjour en m'adressant par mon nom (nous avons parlé un peu de nos puzzles respectifs, mais pas longtemps car un groupe jouait du blues sur scène ce qui complique un peu les conversations... faut dire que ma voix est un peu usée après deux jours complets d'enseignement alors je suis moins de taille à compétitionner avec ce genre d'ambiance  ). En plus du café, nous avons des fruits et des yogourts grecs, ce qui fait tout à fait le travail pour moi (pomme verte croustillante et yogourt aux framboises, excellent!).

Versh, Jon Kalb procède à l'accueil des participant(e)s. Une petite vidéo promotionnelle qui fait un clin d'oeil au dernier Star Wars nous est présentée. Il nous informe que selon les chiffres de Marshall Clow, nous sommes officiellement au-dessus du cap de 900 participant(e)s. On a un présentateur qui a eu un problème d'avion et dont la présentation a été déplacée. Jon Kalb présente les puzzles (mon nom est sur le grand écran; c'est vraiment une drôle d'année) et mentionne que les puzzles proposés peuvent mener à gagner un prix. La présentation de SG14 est indiquée. Semble qu'on doive avoir une étiquette ISO sur notre badge pour y assister (je n'en ai pas, alors je vais aller m'assurer qu'on n'ait pas de problèmes bêtes tantôt).

Vidéo : https://www.youtube.com/watch?v=_wzc7a3McOs&index=2&list=PLHTh1InhhwT7J5jl4vAhO1WvGHUUFgUQH

Diapos : https://github.com/CppCon/CppCon2016/blob/master/Keynotes/The Evolution of C++ - Past, Present, and Future/The Evolution of C++ - Past, Present, and Future - Bjarne Stroustrup - CppCon 2016.pdf

Keynote de Bjarne Stroustrup

Jon Kalb présente ensuite Bjarne Stroustrup.

The Evolution of C++: Past, Present, Future

Bjarne Stroustrup mentionne que 930 badges ont été imprimés. Il dit ensuite qu'étant donné le nombre de présentations techniques au colloque, il a préféré préparer une présentation d'ordre général sur les raisons derrière ce que le langage est, et derrière ce qu'il n'est pas. Il souhaite parler des directions vers lesquelles nous allons maintenant, et vers lesquelles nous iront demain.

Bjarne Stroustrup enchaîne avec une parenthèse philosophique sur la « tension naturelle » entre les principes, les idéaux, et les réalisation concrètes. Bjarne Stroustrup dit qu'il n'aime pas qu'on dise que le succès de C++ repose sur la chance; selon lui, on ne peut pas être chanceux pendant 35 ans.

« Dream no little dreams » : Bjarne Stroustrup souhaite changer la manière par laquelle les gens approchent le code et la programmation, à améliorer les pratiques. Il parle de clarté, résilience, vitesse, utilisation du matériel, et parle aussi de compilation significativement plus rapide que par le passé. Bjarne Stroustrup parle ensuite de Niccolo Machiavelli, qui expliquait les dangers de bousculer l'ordre établi. On se fait des ennemis chez les gens qui tiennent au statu quo.

« The Best is the Enemy of the Good » : Bjarne Stroustrup parle de la valeur d'avancer, de prendre des risques. Il cite ensuite Isaac Newton qui disait reposer sur les épaules de géans, et rend hommage à ceux qui l'ont précédé.

Bjarne Stroustrup présente un graphique de l'évolution de la popularité et de l'utilisation de C++. Il examine les creux et les vagues, et dit qu'on peut s'en inspirer pour comprendre comment nous pourrions alimenter la croissance du langage.

Bjarne Stroustrup place C++ en deux phrases : « correspondance directe avec le matériel », et « abstractions à coût zéro ». Il montre un exemple simple (lire des string dans un vector<string>), une version en deux lignes, simple, et une version très détaillée, longue et laborieuse. C++ permet les deux approches; le souhait de Bjarne Stroustrup est de faire en sorte que la version de deux lignes, qui va à l'essentiel et est facile à comprendre, soit aussi rapide (ou plus rapide!) que la version qui se perd dans les détails. Bjarne Stroustrup critique l'enseignement de la programmation, qui ne suit pas l'évolution du langage et propose encore des approches contre-productives qui découragent les étudiant(e)s des pratiques plus simples, plus saines et (typiquement) plus efficaces. Ce qui compte est d'aller à l'essentiel, d'exprimer ses idées clairement, et il faut que le langage permette d'obtenir des programmes efficaces sur cette base.

Bjarne Stroustrup rappelle qu'un langage requiert de bons mécanismes, mais ne se limite pas à un ensemble de mécanismes. Il parle de l'importance de l'intégration et des outils. Il présente une diapositive expliquant sa liste de caractéristiques générales importantes (stabilité, rapidité, bonnes bibliothèques, etc.), en indiquant qu'elle remonte à 2003. Son plaidoyer pour une programmation qui ne s'adresse pas qu'aux experts, proposé l'an dernier, est résumé dans son discours ici. Il présente une évolution de la répétitive for au fil des ans en appui à son discours. Un graphique résumant les décisions clés dans l'histoire du langage (ce que chaque idée du langage a permis de provoquer comme changement dans les manières de penser). Le graphique met en relief que bien que des évolutions dans les pratiques apparaissent un peu partout, il y a des blocs plus denses lorsqu'une nouvelle version du standard est publiée; c'est à ces moments que les idées éparses prennent forme formellement (!) et arrivent à maturité.

La présentation met en relief que les grands changements ne sont pas tout, bien qu'ils soient importants. Le langage croît aussi par la voie des petits changements et de leur influence dans les pratiques. Et Bjarne Stroustrup rappelle que les grands changements requièrent des décisions qui font mal et brisent l'ordre établi.

Bjarne Stroustrup indique que le fait que les processeurs ont cessé d'accélérer vers 2005 a changé beaucoup de choses dans le monde de la programmation; il est devenu moins pertinent de développer pour un langage qui ne permet pas de tirer le maximum de l'existant.

Bjarne Stroustrup dit que bien que la moitié du standard repose sur des bibliothèques maintenant, sa présentation ne portera pas sur ce sujet. Il présente ses excuses. Il discute ensuite de ce qu'est un bon changement dans le langage, du point de vue des usagers (« je ne veux rien briser; je veux de meilleurs outils ») et des concepteurs (« je veux changer les manières de penser »). Les deux perspectives sont importantes, et il faut ouvrir ses horizons de part et d'autre. La communauté de C++ est immense (des centaines de milliers de programmeuses et de programmeurs) et diversifiée dans ses intérêts.

Bjarne Stroustrup explique sa vision des changements mineurs (séparateurs d'unités dans les chiffres, par exemple), mineurs/majeurs (auto, par exemple) ou majeure (les concepts, par exemple). Certains changements sont isolés (variables globales inline : pas de nouveau mot clé, pas de bris de code existant... Bjarne Stroustrup n'aime pas ce truc du tout  ), d'autres sont plus envahissants (l'unification des méthodes et des fonctions, qui n'a pas passé; Bjarne Stroustrup n'est pas content de ça non plus  ).

Bjarne Stroustrup indique que toute nouvelle extension peut faire du mal, ne serait-ce que parce que cela ajoute à la charge conceptuelle des gens qui approcheront le langage pour l'apprendre. Il se peut aussi que l'ajout d'un nouveau mécanisme nuise à celles et ceux qui ne l'utilisent pas (en C++, on travaille très fort pour éviter ça). Bjarne Stroustrup indique aussi que certains mécanismes ralentissent l'arrivée d'autres mécanismes, qui seraient plus importants. Certains mécanismes peuvent briser le code bruyamment (static_assert, par exemple, une très bonne chose, ou les changements à auto avec C++ 17 qui traiteront mieux les listes d'initialisation)

Bjarne Stroustrup dit que la plupart des gens veulent un plus petit langage, mais qui en fait plus. C'est un idéal difficile à atteindre. Les gens veulent une stabilité et une compatibilité totale avec le passé. Les gens veulent des mécanismes qui sont parfois antagonistes, mutuellement incompatibles. Les gens ne partagent pas les mêmes valeurs et les mêmes philosophies en tout. Évidemment, il faut aussi considérer que le comité de standardisation est fait de bénévoles. Surtout, selon Bjarne Stroustrup, le comité de standardisation est devenu gros, ce qui complique la mise en commun des perspectives. Il faut dire que chaque rencontre du comité est précédée par plus de cent propositions qu'il faut lire et comprendre.

Bjarne Stroustrup discute ensuite des raisons qui mènent à des décisions entre « ceci devrait être dans une bibliothèque » et « ceci devrait faire partie du langage ». Les temps de compilation résultant de ce classement jouent un rôle important dans chacun de ces choix. L'évolution de l'initialisation d'une std::pair est donnée en exemple, de pair<K,V> p{ k,v }; à p = make_pair(k,v); à pair p{k.v};.

Bjarne Stroustrup propose quelques pistes d'évolution, et dit souhaiter intégrer rapidement et prendre plus de risques. Le risque de ne rien faire, de ne pas prendre assez de risques, est évoqué. Il met en garde les gens sur place de ne pas confondre familiarité et simplicité. Il faut accepter que nous ferons des erreurs.

Bjarne Stroustrup pose la question de la caractérisation de C++ : à quoi sert ce langage? À qui est-il destiné? Qu'est-ce qui le rendrait meilleur? On ne peut être toute chose pour chaque personne, après tout... Bjarne Stroustrup dit que nous avons vraiment besoin de plus de buzzwords 

Bjarne Stroustrup se permet une boutade à l'effet qu'on ne rendra jamais le langage assez « beau » pour que tous les professeurs souhaitent s'en servir pour enseigner la programmation aux débutant(e)s.

Pour le futur, Bjarne Stroustrup souhaite améliorer le support à la concurrence, aux programmes de grande envergure, simplifier le langage au quotidien (pour les tâches courantes), réduire les risques d'erreurs bêtes, le tout en maintenant les forces du langage. Ne pas abandonner le passé, évidemment. Il fait un retour sur sa vision, il y a un an, de ce qui se trouverait dans C++ 17 et fait le constat qu'il était optimiste. Bjarne Stroustrup montre ce que nous aurons, une longue liste mais de trucs qu'il estime dans la catégorie « mineurs ». Il accepte toutefois que tous vont apprécier ces ajouts, et que la vie de tous et chacun sera améliorée par l'évolution du langage, mais il trouve que nous n'avançons pas assez rapidement.

Pour C++ 20, Bjarne Stroustrup veut tout ce qu'il voulait pour C++ 17, en plus de la surcharge de l'opérateur « . » et des comparaisons par défaut. Dans les souhaits, on trouve une simplification du déploiement, des mécanismes pour faciliter la réflexivité statique, le Pattern Matching comme on en trouve dans la programmation fonctionnelle, et de meilleurs outils pour gérer la concurrence. Il est triste de la petite quantité d'ajouts majeurs dans C++ 17.

Bjarne Stroustrup enjoint tous les gens à migrer rapidement au moins à C++ 14, pour commencer à se préparer pour le futur en apprivoisant le présent. Poser ce geste rendra d'office les programmes plus rapides et plus robustes. Il enjoint aussi les gens à apprivoiser les modules (chiffres à l'appui pour montrer à quel point ils peuvent réduire l'effort de compilation), les concepts (dont il fait l'éloge), les coroutines et les contrats. Il accompagne cette recommandation de stratégies pour fins d'intégration graduelle des nouveaux mécanismes. Il présente les Structured Bindings, qui sont un des chics nouveaux mécanismes de C++ 17. Il mentionne par contre que pour le moment, tous les compilateurs offrent certains de ces mécanismes, pas tous, ce qui complique l'acte d'expérimenter avec le tout. Il demande aux vendeurs de compilateurs de faire un effort pour nous permettre collectivement d'avancer.

Bjarne Stroustrup fait un retour sur la GSL, sujet de son discours de 2015, et sur les vertus de cette approche à ses yeux. Il fait un retour sur la Type-Safety et la Resource-Safety, pour parler de l'interaction entre les mécanismes de bas niveau, reposant entre autes sur l'analyse statique, ceux qui reposent sur les abstractions du langage, ceux qui reposent sur l'hygiène et les pratiques d'entreprise, etc. Il discute d'une règle à propos du passage d'un tableau en paramètre à une fonction, des enjeux., des raisons, des conséquences...

J'ai manqué la fin de la présentation car mon ordinateur s'est éteint subitement. En gros, Bjarne Stroustrup a fait un tour récapitulatif de la présentation et a commencé à accepter les questions du public.

Q : comment les templates et les modules interagissent-ils?

Bjarne Stroustrup : très bien. Surtout si on ajoute les concepts. Je veux accélérer la compilation. On peut le faire en poussant tout au moment d'exécuter le programme, mais ce n'est pas ce que je veux..

Arthur O'Dwyer : pourquoi l'évolution du langage a-t-elle ralenti vers 2000?

Bjarne Stroustrup : nous avions mal compris les règles d'ISO et nous pensions devoir attendre. Nous étions fatigués, il faut l'avouer. La fin de l'évolution de la vitesse des processeurs nous a beaucoup aidés.

Q : comment peut-on obtenir un meilleur support des nouveaux mécanismes du langage au quotidien?

Bjarne Stroustrup : faites de la pression sur les vendeurs de compilateurs.

Q : comment profiter du nouveau matériel?

Bjarne Stroustrup : mécanismes de meilleure qualité pour la gestion de la concurrence et la gestion de la Cache. C'est surtout du côté des bibliothèques.

Q : sur la courbe présentée, quel fut l'impact des gens qui ont aidé à publiciser le langage et qui en ont parlé dans Internet? Cette information est beaucoup plus facile à trouver maintenant qu'auparavant.

Bjarne Stroustrup : le comité était fatigué et nos ressources sont limitées. Nous n'avions pas de site Web (ça s'améliore maintenant) pour proposer un point d'ancrage officiel. Il nous manquait certaines bibliothèques dans le standard parce que certaines firmes contribuant au standard poussent des technologies qui se font concurrence. Comment se fait-il que nous n'ayons pas de bibliothèque standard pour le Web en 2016?

Q : quel est le rôle de Boost dans l'évolution de C++?

Bjarne Stroustrup : elle a été importante, pour la communauté et pour le standard. Maintenant, j'aimerais qu'il y ait des paquetages Boost pour débutants, intermédiaires et experts (quelqu'un tente de l'interrompre un peu rudement, mais Bjarne Stroustrup l'invite à venir poser ses questions ce soir lors du panel avec des membes de WG21).

Petite marche en direction du 4e étage, quelques échanges de sourires et de politesses avec les gens charmants qui ont participé à mon cours de la fin de semaine. Certain(e)s veulent savoir comment obtenir l'autocollant ISO pour participer à la rencontre officielle de mercredi, alors je suis passé voir Michael Wong dans le but de lui suggérer de l'expliquer dans sa présentation. Il m'a informé que pour les membres actifs du comité, cela va d'office, mais je ne suis plus vraiment inquiet pour moi.

Diapos :

Vidéo : https://www.youtube.com/watch?v=dMupATOJKWc&index=60&list=PLHTh1InhhwT7J5jl4vAhO1WvGHUUFgUQH

Présentation de Guy Davidson, Nicolas Guillemot, Sean Middleditch et Michael Wong

Beaucoup de gens dans la salle, beaucoup de visages connus. Guy Davidson prend la parole.

WG21-SG14: Making C++ better for games, embedded and financial developers

Guy Davidson : à CppCon 2014, nous avons formé SG14 en réponse aux besoins spécifiques du monde des systèmes à basse latence et des systèmes en temps réel.

Guy Davidson : en 2016, les gens du monde de la finance ont commencé à prendre plus de place dans le groupe. Le pseudo groupe d'études sur les systèmes embarqués, dirigé par Daniel Gutson, s'est joint à nous.

Guy Davidson : nous échangeons beaucoup sur les listes de diffusion, et notre groupe a un excellent rapport signal / bruit. Nous avons un répertoire GitHub et plusieurs téléconférences.

Guy Davidson présente Michael Wong. Guy Davidson demande ensuite si des gens dans la salle jouent à des jeux, et la majorité des gens lèvent la main. Guy Davidson relate une discussion avec Scott Meyers à propos des besoins spéciaux du monde du jeu (Scott Meyers : « tout le monde a des besoins spéciaux »; Guy Davidson : « oui, mais nous, c'est vrai »).

Guy Davidson décrit quelques trucs de développement (exécuter un monde à 10 Hz, forcer le recours strict à deux coeurs. utiliser un GPU, intégrer le son). Il discute ensuite de CPU, RAM, GPU et d'optimisation.

Guy Davidson explique que l'industrie du jeu semble avoir standardisé sur architecture x86, ce qui simplifie un peu le travail.

Guy Davidson : on travaille sur les nombres à virgule fixes, des conteneurs, la concurrence, RCU, les Hazard Pointers, programmation hétérogène, la vectorisation, etc.

Guy Davidson fait un rappel de coprocesseurs mathématiques particuliers (celui accompagnant le 486), et fait un lien avec les trois propositions concurrentes pour l'intégration de nombres à virgule fixe dans le standard. Il en profite pour expliquer le besoin pour ce type (belle description, que je ne peux pas related ici faute de taper assez vite). Guy Davidson dit que le problème de la précision est bien réel, et que migrer de float vers double en pratique n'est pas pratique : puisque tout objet a une position dans un jeu, ceci doublerait la taille des données en mémoire. L'idée des nombres à virgule fixe est d'avoir une distribution homogène des valeurs sur une plus petite plage de données (les nombres à virgule flottante représentent une plage plus vaste, mais leur densité est forte près de zéro et se disperse en s'éloignant). Guy Davidson discute ensuite des enjeux de représentation, d'arrondi, et d'autres enjeux techniques reliés à ce type.

Guy Davidson enchaîne pour discuter de conteneurs : ring, flat_*, les outils de gestion de mémoire, colony et stack. Ils les explique un à un, en commençant par ring (son bébé). Il parle de Parkinson's Law of Triviality (aussi nommée Bikeshedding  ), puis relate le cheminement de ring jusqu'ici, pour expliquer les affres de travailler en comité.

Sean Middleditch prend le relais et explique d'abord les conteneurs flat_* et leurs enjeux. Un bon résumé.

Par la suite, Sean Middleditch fait la présentation des algorithmes de mémoire brute proposés par Brittany Friedman et acceptés dans C++ 17. Il montre que la plupart des bibliothèques standards utilisent de tels outils, mais qu'ils n'étaient pas standards et pour usage public.

Sean Middleditch enchaîne avec colony et stack. Les enjeux sont des insertions et des suppressions fréquentes en temps réel, et ne doivent pas invalider les itérateurs utilisés ailleurs dans le conteneur. Il mentionne aux intéressé(e)s que Matthew Bentley en parlera cet après-midi.

Sean Middleditch poursuit avec les API graphiques 2D. Elles ne se destinent pas aux jeux 3D sur console, mais Sean Middleditch rappellent que plusieurs jeux sont en fait 2D en pratique. Sean Middleditch rappelle que programmer sur console, c'est un peu moche. La propositon sur la table pose problème à certains égards, en particulier du fait que l'API proposée est Stateful. Le problème de la gestion des entrées s'adjoint à ce dossier.

Michael Wong prend la scène. Il présente son (!) rôle dans SG14 et SG5, puis donne un aperçu de la rencontre de mercredi cette semaine, tout en expliquant le fait qu'il s'agit d'une rencontre ISO officielle avec ce que ça comporte. Il mentionne être particulièrement intéressé par la question de la programmaiton de systèmes hétérogènes.

Michael Wong situe WG21 au centre de SG1 (concurrence et parallélisme), SG5 (mémoire transactionnelle) et SG14. Il aborde ensuite la question des exécuteurs, et le fait que plusieurs propositions concurrentes sont sur la table, et que nous avons un design mnimal sur la table.

Michael Wong enchaîne sur la question de la concurrence, et mentionne Paul E. McKenney et Maged Michael, deux des plus grands experts au monde sur le sujet. Michael Wong va très rapidement alors je ne prends qu'une infime partie de ce qu'il dit. Il aborde les registres SIMD et les travaux de Matthias Gaunard. Il passe ensuite sur les propositions qui recoupent la programmation de systèmes hétérogènes, et les met en valeur (mais on peut le comprendre).

Michael Wong conclut sur l'intégration du monde de la finance dans SG14, à la suite des intervenants du monde du jeu. Il associe mon nom au concept de « exception handling lite ». Il invite les gens à s'intégrer à SG14 et à contribuer. À l'oeil, il doit passer dix diapos par minute.

: comment contribuer à SG14?

Michael Wong : commence par la liste de diffusion.

: qu'est-ce qu'il y a d'étrange avec les exceptions dans un algorithme parallèle?

Michael Wong : c'est plus facile d'élargir le mécanisme que de le restreindre ultérieurement.

: vise-t-on encore des exceptions à la compilation?

Michael Wong : je pense que oui mais je ne suis pas certain.

Mon ordinateur me cause des ennuis, et je n'ai pas de réseau. Je ne sais pas pourquoi Nicolas Guillemot n'est pas allé sur scène; j'imagine que je l'apprendrai en chemin... J'ai eu le plaisir de bavarder avec Isabella Muerte, Brittany Friedman et un de ses collègues brièvement; Isabella Muerte m'a dit avoir résolu mes trois petits puzzles mais avoir triché pour résoudre le premier. Mateusz Pusz est ensuite passé pour me dire que le premier puzzle lui cause des maux de tête, ce qui est plutôt amusant. J'ai reçu par la firme qui gère le puzzle un mot à l'effet que 1660 personnes sont allées visiter le site, et que 93 ont réussi les trois étapes.

Un des participants de ma classe est ensuite venu s'asseoir pour bavarder de l'enseignement de l'informatique, des difficultés de recrutement de son entreprise – il était d'avis que l'on ne donne en général pas une formation assez variée (trop de Java, pas assez d'autres trucs, essentiellement; le problème n'est pas Java, évidemment : c'est le manque de variété) pour que les étudiant(e)s sortent de l'école compétent(e)s, du moins aux États-Unis. Il m'a ensuite raconté un problème qu'il venait de vivre dans son entreprise et qu'il réglait la nuit et pendant le cours, car c'était critique, dans la firme de transactions financières où il opère (un bogue qui aurait pu mener à un changement des demandes d'achats et de ventes sans autorisation... Ouch!). Sympathique échange, mais je n'ai pas eu le temps de dîner (il n'y a rien de parfait).

Les problèmes de réseau récurrents semblent dûs aux fait que certains abusent et téléchargent des documents monstrueux / regardent des vidéos HD. Les ressources du bâtiment sont utilisées au maximum et sont prévues pour 2000 personnes. C'est très agaçant de perdre le contact avec le monde extérieur – et avec ma belle! – sans cesse.

Diapos (on parle des mêmes diapos pour les parties I et II) : https://github.com/CppCon/CppCon2016/blob/master/Presentations/What is the basic interface/What is the basic interface - Lisa Lippincott - CppCon 2016.pdf

Vidéo : https://www.youtube.com/watch?v=s70b2P3A3lg&index=58&list=PLHTh1InhhwT7J5jl4vAhO1WvGHUUFgUQH

Présentation de Lisa Lippincott I

La salle est pleine aux deux tiers. Lisa Lippincott nous propose de nous paqueter dans la section centre et la section droite de la salle pour lui faciliter la vie (on est dans la salle où j'ai enseigné en fin de semaine). Je fais mon « pas fin » et je reste à l'extrême droite de la partie gauche de la salle car je vois bien et j'ai une prise de courant.

Un bénévole vient nous informer de l'importance de ne pas télécharger des monstres dans un bâtiment où se trouvent près de 1000 informaticien(ne)s en même temps... >soupir!<

What is the basic interface? (1 de 2)

Il est important pour comprendre la démarche de Lisa Lippincott de savoir qu'elle s'inscrit résolument dans l'étude formelle du paradigme procédural et impératif.

Lisa Lippincott : trois éléments clés :

Lisa Lippincott : pourquoi les ordinateurs ne valident-ils pas nos preuves? C'est parce que ce qu'on cherche à prouver n'est pas clair. Nos interfaces ne sont pas assez formelles, elles manquent de détail, et nous ne sommes pas d'accord sur ce qui peut rester dans le domaine du « non-dit ».

Lisa Lippincott : le problème clé est la gestion du changement. On a essayé d'exprimer des programmes où rien ne change, sans succès. Je propose de mieux représenter le changement. Ce qui importe est de spécifier les attentes quant à une fonction. Lisa Lippincott dit qu'elle va inventer du vocabulaire :

inline result_type f(params...) { ... prologue ... implementation(); ... épilogue ... }

Ici, f() est l'interface pour implementation();, qui est une fonction de même signature.

Un appel est séparé en une région « pré-appel », un appel et une région « post-appel ». L'idée est d'en arriver à un raisonnement le plus local possible. Le prologue est responsable pour le comportement lors de l'appel, alors que l'épilogue est responsable pour le comportement avant retour au post-appel. Ces responsables doivent arrêter la mécanique s'il y a un contrat. L'appelant vit dans une unité de traduction; l'interface fait de même, et l'implémentation fait de même. Ceci permet des preuves par composition.

L'interface de base est  :

inline result_type f(params...) {
   // pas de comportement indéfini ici (par définition; pas besoin de l'écrire)
   implementation();
   // pas de comportement indéfini ici (par définition; pas besoin de l'écrire)
}

En raffinant le tout, on arrive à :

inline result_type f(params...) {
   // pas de comportement indéfini ici (par définition; pas besoin de l'écrire)
   try implementation() {
      // pas de comportement indéfini ici (par définition; pas besoin de l'écrire)
      return ...
   } catch (...) {
      // pas de comportement indéfini ici (par définition; pas besoin de l'écrire)
      throw;
   }
   // pas de comportement indéfini ici (par définition; pas besoin de l'écrire)
}

Lisa Lippincott suit avec des exemples de ce qu'elle a en tête. En plaçant des cas d'erreurs possibles, elle pousse des assertions comme claim writable(x) sur un x passé par référence dans l'interface. Le terme claim serait un qualificateur existentiel sur les chemins d'exécution. La fonction writable() a pour objectif de mener à du comportement indéfini si l'affirmation ne s'avère pas, ce qui brise le contrat selon lequel on éviterait le comportement indéfini. La fonction readable() a le même effet pour l'essentiel. Ces deux fonctions sont des capacités (capabilities), dans sa terminologie. S'ajoute à cela des trucs pas gentils comme détruire un objet dans l'implémentation, qui peuvent être validés par readable() et writable() dans l'épilogue.

Lisa Lippincott : « if you're thinking 'don't do that!', then 'don't do that!' is probably part of the basic interface » 

Lisa Lippincott ajoute claim proper pour les entiers qui sont à la fois readable et writable. C'est par proper que l'on aménagera en quelque sorte les invariants, même si les deux trucs ne sont pas vraiment une seule et même chose. Elle ajoute des qualifications pour soustraire certains paramètres à certaines affirmations, par exemple [improper]. Lisa Lippincott mentione toutefois que son formalisme est perfectible sur ce point. Elle fait remarquer que dans le traitement d'une exception, il est typiquement risqué de faire un claim plus fort dans un épilogue que dans un prologue.

Lisa Lippincott retravaille la définition de writable. La construction d'un entier e implique writable(e), une conséquence de l'encapsulation à mon sens.

Lisa Lippincott ajoute la capacité destructible(), qui est une autre propriété importante d'un objet.

Lisa Lippincott revient sur le volet où l'appelant appelle indirectement l'implémentation à travers l'interface : à ce stade, dans le prologue, localement et par construction, on peut écrire dans les writable, on peut lire les readable, et on peut détruire les destructible. De même, dans l'épilogue, seuls les localement readable sont lus, seuls les localement writable sont modifiés et seuls les localement destructible sont détruits.

Lisa Lippincott : est-ce que destructible fait partie de proper, donc de l'interface de base? L'ennui est que destructible est une fonction diablement dangereuse... On a besoin de cela pour les claim destructible applicables aux valeurs retournées des fonctions, et aux exceptions attrapées.

Lisa Lippincott : dans un constructeur, posit desctructible(*this) s'applique. Le mot posit une assertion dangereuse car elle est universelle. Dans le destructeur, au début, on a un claim destructible(*this). Elle ajoute aussi claim unoccupied_space(*this) pour permettre la réutilisation de la mémoire (par std::launder(), par exemple). Il y a des conséquences à claim destructible() si on n'est pas prudents, soit les cas de double destruction; on a aussi des risques de fuites si on utilise ces affirmatons incorrectement.

Lisa Lippincott demande si la lisibilité ou « l'écrivabilité » font partie de l'interface de base. Selon elle, mieux vaut exiger ces propriétés au point de destruction pour s'assurer qu'elles y disparaissent.

Q : comment peut-on généraliser ceci à tous les types?

Lisa Lippincott : elle explique le sens à donner à un proper vector<T> ou à un proper <const vector>.

On prend une pause vers 15 h. C'est vraiment très intéressant; des amis comme Vincent Echelard ou Marc Frappier auraient adoré. Gabriel Aubut-Lussier, qui est dans la salle mais que je n'avais pas vu, semble aussi très enthousiaste. Faut aimer l'abstraction et la rigueur, évidemment.

Je me cherche quelque chose à manger à la pause, car n'ayant pas dîné, je m'endors un peu, mais il n'y a rien. Je triche en me prenant du thé glacé (pas sucré, heureusement) pour le bourrer de citrons (mioum!) le temps de me rendre au souper. Je passe par la salle d'Arthur O'Dwyer pour prendre de ses nouvelles; ça semble bien aller pour lui aussi, et les gens sourient et posent des questions. Il m'avoue toutefois être en retard de 20 diapos sur son plan de match. Un étudiant d'hier vient me faire part qu'il a aimé, ce qui est toujours chouette 

Au retour dans la salle, je croise Casey Carter, Marshall Clow et Beman Dawes qui bavardent. Je suis content de voir que Beman Dawes a pu venir cette année encore (il ne voyage pas tout le temps).

Diapos : (on parle des mêmes diapos pour les parties I et II) : https://github.com/CppCon/CppCon2016/blob/master/Presentations/What is the basic interface/What is the basic interface - Lisa Lippincott - CppCon 2016.pdf

Vidéo : https://www.youtube.com/watch?v=Uzu5CuGfmGA&index=57&list=PLHTh1InhhwT7J5jl4vAhO1WvGHUUFgUQH

Présentation de Lisa Lippincott II

On reprend les hostilités (!) vers 15 h 15. Dans un événement de cette taille, il faut que tout le monde gère le temps avec rigueur.

What is the basic interface? (2 de 2)

Lisa Lippincott reprend avec son étude des cas problèmes avec une fonction prenant deux paramètres par référence, f(T&,const T&), détruisant le premier pour reconstruire dans la même zone à partir de la valeur du second, montrant qu'on pourrait passer le même objet pour les deux paamètres, f(a,a), et tout casser.

Lisa Lippincott dit que selon elle, la clé n'est pas de chercher si un paramètre est un alias pour un autre, mais bien de suivre le chemin à partir de la construction des objets. À l'origine, un objet n'est un alias que pour lui même; ce qu'il faut est suivre cette relation à même l'interface. Elle définit irresponsibly aliased quand un alias n'est pas communiqué à travers une interface. Quelqu'un souligne le problème des membres d'un même struct; elle exprime de concept en termes d'alias internes.

Lisa Lippincott exprime cette relation d'alias irresponsable en termes de writable et de destructible. Elle montre comment cela permet de détecter les bris de contrat. Elle introduit ensuite claim aliased(x,y) pour relaxer certaines contraintes quand cela ne pose pas de problème. Quelqu'un demande si cette marque signifie « peut être un alias » ou « doit être un alias »; Lisa Lippincott dit que pour le moment c'est un « doit ». Marshall Clow suggère qu'il soit facile de se débarrasser de cette affirmation et d'en faire un noop. Lisa Lippincott suggère d'écrire if(&x==&y) claim aliased(x,y) tout simplement. Ça impose par contre une analyse dynamique, pas statique (quoique... je ne suis pas sûr, vu qu'on parle d'adresses plutôt que de valeurs).

Lisa Lippincott parle des interfaces de fonctions comme memmov(dest,src,n), qui fonctionnent même si les plages se chevauchent.

Lisa Lippincott indique que toute affectation, en retournant une référence, retourne un résultat « impropre » au sens de l'interface de base. Cela peut être un truc comme claim aliased(result,x) quand result est une référence sur x, ce qui permet une meilleure analyse par le compilateur.

Lisa Lippincott demande si les tests conditionnels sur les alias en prologue et en épilogue devraient faire partie de l'interface de base; cela permettrait de considérer swap() par exemple. Elle dit que le défaut est que la preuve devient nettement plus complexe si on admet ces relations. Elle conclut que l'interface de base n'est pas bonne pour toutes les fonctions.

Lisa Lippincott passe au travers son matériel de base; elle sort ses diapositives « bonus »  Elle parle d'une fonction comparant deux const int* et retournant un const int* en réalisant le test à travers std::less<const int*>. Ensuite, elle fait une manoeuvre semblable mais en retournant la valeur pointée par la plus petite adresse. Elle fait remarquer que ceci pose entre autres le problème qu'en créant copies des objets d'origine, on risque d'avoir des résultats asymétriques du fait que les adresses des temporaires peuvent ne pas avoir la même relation que celle qui gouverne les adresses des originaux.

Lisa Lippincott ajoute la relation « indiscernable », montre comment en profiter. Des tas de trucs sont indiscernables (elle en fait une liste). Par exemple, le padding dans un POD est indiscernable du point de vue de readable. L'ordre des bytes dans un entier non plus, du moins du point de vue de readable. Le caractère indiscernable signifie qu'on ne peut dépendre de la propriété. Lisa Lippincott estime que readable est un prérequis pour indiscernable.

Lisa Lippincott : le gross input d'une fonction est l'ensemble des valeurs qui sont localement readable (les rvalue accessibles du prologue). Le gross output est l'ensemble des rvalue mentionnées dans l'épilogue. À ses yeux, le net input est le gross input modulo les changements indiscernables, et le net output est le gross output modulo les changements indiscernables. Ça donne :

   Gross input ----> Indiscernable ----> Gross input
      |                                     |
      |                                     |
      |                                     |
Appel de fonction                   Appel de fonction
      |                                     |
      |                                     |
      |                                     |
  Gross output ---> Indiscernable ---> Gross output

Lisa Lippincott ajoute irresponsibly indiscernible pour le cas où le caractère indiscernable n'est pas communiqué de l'appelant vers l'appelé, ou retourné de l'appelé vers l'appelant. Pour couvrir ce cas, elle propose de conserver à même le prologue le calcul sur la base duquel le caractère indiscernable repose.

Sa dernière diapo formalise l'ensemble du discours. C'est un résumé formel très intéressant; je vais essayer de mettre la main dessus.

Lisa Lippincott reprend le même formalisme sur les méthodes d'instance, car il y a des petites nuances sur la bases des attributs d'instance, des constructeurs, des destructeurs, de l'héritage.

Plusieurs questions restent en suspens : les capacités des types composites, celles des types polymorphiques, celles des types incomplets, les interfaces des opérateurs (en particulier new et delete), les interfaces des fonctions répétables ou éliminables par voie d'optimisation, etc.

Q : comment ceci s'articule-t-il en comparaison avec les contrats?

Lisa Lippincott : les contrats sont très fonctionnels. Je pense que les preuves doivent couvrir le code procédural aussi. Les contrats sont utiles mais ne vont pas là où je veux aller.

Q : je n'ai pas vu de structures de contrôle dans l'épilogue...

Lisa Lippincott : coup de chance. Il y a toujours des effets de bord.

: quoi penser d'un return hâtif?

(j'ai manqué la réponse, tristement)

Lisa Lippincott revient sur les structures de contrôles dans les prologues et dans les épilogues. Elle indique qu'un vecteur proper implique que ses éléments sont aussi proper, et parle d'autres caractéristiques, mais indique que valider ces trucs implique une boucle. Lisa Lippincott est d'avis que la propriété de Reachability est anologue à une boucle. Casey Carter pense que non, et donne l'exemple des passages unidirectionnels sur un input_iterator. Lisa Lippincott suggère de mettre ces trucs dans une fonction inline pour en faire une affirmation sur le code qui n'a pas à être répétée.

: je n'ai pas vu de posit dans les diapositives de résumé...

Lisa Lippincott montre un cas.

Une discussion s'ensuit sur le sens formel de unoccupied_space(). C'est profond est subtil.

On ferme vers 16 h 15. Gabriel Aubut-Lussier et moi bavardons le temps d'aller manger une bouchée (des quesadillas, végétariens ou non, les deux délicieux... Mioum! Je commençais à avoir pas mal faim!).

Je bavarde avec Arthur O'Dwyer qui reprend son souffle après deux heures de prestation, et me confie être épuisé. On rit un peu. J'ai aussi re-croisé ce très chic Mitch Carlson qui semblait d'excellente humeur.

Je m'installe dans la salle où se tiendra la présentation de Paul E. McKenney et je bavarde avec un de mes étudiants de la fin de semaine, qui me dit adorer son séjour jusqu'ici. J'en suis ravi! 

Diapos : https://github.com/CppCon/CppCon2016/blob/master/Presentations/Beyond the Issaquah Challenge/Beyond the Issaquah Challenge - Paul McKenney - CppCon 2016.pdf

Vidéo : https://www.youtube.com/watch?v=qcD2Zj9GgI4&list=PLHTh1InhhwT7J5jl4vAhO1WvGHUUFgUQH&index=33

Présentation de Paul E. McKenney

On commence à 16 h 45.

Beyond the Issaquah Challenge: High-Performance Scalable Complex Updates

Paul E. McKenney fait un retour sur le problème couvert à CppCon 2014, et portant sur la mise à jour atomique et concurrente de parties d'une structure de données, le tout sans contention. L'idée est d'éviter les verrous.

Paul E. McKenney dit qu'il aurait pu publier des résultats depuis longtemps, mais ne voulait pas deux implémentations distinctes (RCU et atomiques). Les chiffres de base qu'il obtient sont douloureux, et l'échelonnabilité est terrible, entre autres à cause des lois de la physique : à l'échelle du nanomètre, la vitesse de la lumière devient une limite agaçante. Aussi, les atomes ne sont pas de taille nulle, ce qui influence la vitesse des transistors. Enfin, Paul E. McKenney avoue ne pas avoir compris comment faire abstraction des lois de la physique, alors il a décidé de tricher.

Paul E. McKenney parle d'accès Read Mostly. Si tu répartis les données convenablement, et si elles sont en Cache, t'as pas mal. Le problème est qu'il arrive qu'on écrive quelque part, et c'est la catastrophe. Conséquence : écrivez le moins possible. Et si vous devez le faire, assurez-vous que les processeurs ne voient que de petits morceaux et interfèrent le moins possible les uns avec les autres.

Paul E. McKenney indique que les arbres sont chouettes car leurs noeuds sont éparpillés. Les tables de hachage, c'est plus complexe.

Paul E. McKenney indique que RCU insiste sur la lecture, et fait des efforts pour que les écritures soient le moins dommageables possibles sur le système dans son ensemble.

 Les opérations de RCU reposent sur des tricheries. Paul E. McKenney explique sa stratégie mais il va très vite. Heureusement, c'est pas mal les mêmes diapos que par le passé.Et rcu_read_lock() et rcu_read_unlock() sont des outils d'ingérierie sociale (elles ne font rien, outre discipliner les programmeuses et les programmeurs!).

Il y a une hiérarchie de cas avec RCU : ça va très bien avec Read Mostly et pas de besoin de cohérence de données, Ok si la cohérence des données est requise, et ça va pas mal moins bien quand on parle d'Update Mostly. Le truc est de faire le maximum avant d'aller prendre un verrou.

Paul E. McKenney recommande d'utiliser RCU, qui est spécialisé, en combinaison avec d'autres outils de synchronisation. Il explique sa solution de base (CppCon 2014) au Issaquah Challenge. Pour les mises à jour de relations entre deux noeuds, il y a quatre cas, mais Paul E. McKenney suggère d'y aller simplement : si les attentes ne sont pas rencontrées, on abandonne et on recommence. Ça tend à se régler tout seul. Il utilise aussi une Existence Structure où il gruge quelques bits de pointeurs pour d'autres fins (pas propre, mais il dit « d'autres l'ont fait, je le fais aussi »). Il s'en sert pour permuter une feuille de deux arbres distincts de manière atomique (ça prend d'ailleurs des manipulations atomiques pour y arriver).

Paul E. McKenney trace des liens entre sa technique et ce qu'on voit apparaître dans des implémentations de mémoire transactionnelle.

Paul E. McKenney montre les chiffres obtenus jusqu'ici; ça va bien jusqu'à une utilisation d'une demi-machine, mais ça sous-utilise la deuxième moitié des processeurs. Pour en arriver à mieux, il a dû retravailler ses algorithmes. Il utilise des noeuds incoming et outgoing entre des tables de hachage et des noeuds; ces noeuds sont des sortes de marqueurs d'existence, qui lui permettent d'empêcher un lecteur de constater la rotation des noeuds entre les tables de hashage. Il parle de New-Age Existence Structures. Les résultats de base : pas terribles.

Après les tables de hachage, Paul E. McKenney passe aux Skip Lists. Ça donne des résultats... décevants. Les verrous interfèrent entre eux. Il essaie d'étendre sa stratégie à des permutations de paires de noeuds dans une table de hachage, puis de paires de paires de noeuds, puis... poour se rendre jusqu'à un arbre. Il obtient un zigzag (c'est amusant) mais qui converge asymptotiquement d'une manière presque satisfaisante.

Paul E. McKenney fait ensuite le constat qu'en faisant trois permutations de noeuds, les noeuds reviennent à leur point de départ, alors il peut en pratique ne pas faire d'allocation dynamique de mémoire et jouer avec des bits d'identification. Il utilise une Kaleidoscope Structure et fait une rotation entre une table de hashage et une Skip List. Ça donne de bons résultats et il s'en sort avec la moitié des coeurs sollicités par un seul thread; le problème est que c'est extrêmement spécifique, extrêmement rapide, et d'une utilité limitée.

Paul E. McKenney dit avoir essayé de s'en sortir avec des trucs de C++, par exemple des templates, et que ça a été pour lui... une expérience 

Paul E. McKenney soulève la question : quand utiliser cette technique? Il n'est pas sûr. Il donne quelques pistes. Je sais une chose, personnellement : c'est un truc à encapsuler, pas à exposer! Paul E. McKenney indique que cette technique n'est pas prête pour production. Pour l'IoT, c'est un gros, gros problème.

Paul E. McKenney recommande, en fin de parcours, d'utiliser le bon outil pour le boulot à accomplir.

: comment les lecteurs sont-ils protégés par ta technique?

Paul E. McKenney : le truc est l'Acquire-Load (faut voir la diapo pour suivre).

Quelques questions suivent sur la robustesse de la technique; en gros, le truc de Paul E. McKenney est l'encapsulation, même manuelle (car il programme principalement en C).

On ferme vers 17 h 48. L'ami Matt P. Dziubinski, que je croise à l'occasion dans ces événements, est venu me parler d'un problème d'optimisation d'accès à la Cache auquel il fait face ces jours-ci. On a échangé des idées, je lui ai donné une piste, il m'a proposé un lien. Bien sympathique.

Je sors prendre une marche et essayer de trouver une épicerie pour me prendre un petit quelque chose à manger et une bière car je dois préparer ma présentation de demain matin. Il se trouve qu'il y a une épicerie QFC, le même genre d'épicerie en partie bio que je fréquente normalement quand je viens par ici, à deux coins de rue de l'hôtel où je suis logé. J'ai trouvé un sandwich chou et poulet, correct (je n'ai pas le nécessaire pour cuisiner, tristement) et un inventaire de bières très correct. Je ne suis pas couché ce soir alors prendre un verre en travaillant rendra le tout plus agréable.

J'ai donc mangé une bouchée, parlé avec ma belle Za, et travaillé un peu sur ma présentation de demain matin.

Vidéo : https://www.youtube.com/watch?v=CPgxw1EzC54

Panel – Grill The Committee

De retour  sur les lieux du colloque, Herb Sutter joue un peu de piano pour nous accueillir. Le panel est constitué de plusieurs sommités.

Participants : Bjarne Stroustrup, Hans Boehm, Richard Smith, Casey Carter, Marshall Clow, Michael Wong, Herb Sutter et Chandler Carruth

Jon Kalb est à l'animation. Il dit qu'on ne fera pas une soirée de pirates. La première question porte sur le rôle des individus et leur temps sur le comité.

Bjarne Stroustrup se dit fouteur de trouble en chef, et était sur le comité avant qu'il n'existe.

Hans Boehm dirige le groupe d'études sur la concurrence et est sur le comité depuis environ 2004.

Richard Smith est l'éditeur du standard et siège sur le comité depuis 2012, juste avant la livraison formelle de C++ 11. Jon Kalb demande ce que signifie être Project Editor, et Richard Smith explique.

Casey Carter est l'éditeur pour le Ranges TS et n'est sur le comité que depuis peu.

Marshall Clow est au comité depuis 2012, et dirige LWG car il n'a pas su s'esquiver.

Michael Wong est au comité depuis 2002 ou 2003, juste après son mariage. Il dirige SG14 et SG5 (mémoire transactionnelle). Il est aussi l'éditeur de TS sur la concurrence.

Herb Sutter est sur le comité depuis près de 20 ans, et est le Convenor depuis la moitié de la vie du comité.

Chandler Carruth est sur le comité depuis 2012 et dirige le groupe d'étude sur la réflexivité.

Jon Kalb dit que chacun d'eux programme en pratique, et dit souhaiter que chacun parle d'un mécanisme de C++ dont il a découvert une utilité surprenante récemment.

Chandler Carruth travaille sur LLVM, et cherchait à mettre à jour des composants dans un graphe. Il s'est aperçu qu'il ne lui fallait qu'une recherche en profondeur et un appel à std::partition(). Hommage à Sean Parent.

Herb Sutter dit que C++ 11 est étonné du support accru pour les allocateurs; dans le dernier mois, cela l'a rendu heureux car il s'est aperçu que les allocateurs pouvaient offrir des pointeurs intelligents. Il recommande de profiter du boilerplate d'Howard Hinnant par contre.

Michael Wong dit avoir développé des Hazard Pointers à partir de Polymorphic Resources. L'allocateur est surprenant.

Richard Smith dit que les λ ont transformé sa pratique.

Bjarne Stroustrup cherchait à créer un truc de type Plug and Play. L'existence de concepts (simulés), d'alias pour les templates et les λ lui ont permis de faire ce qu'il voulait presque sans le moindre coût. Il dit aussi que les Scope Guards ont un peu réinventé la roue.

Jon Kalb : quel est votre partie préférée de C++ 17?

Chandler Carruth : Structured Bindings

Herb Sutter : Structured Bindings

Michael Wong : Parallel STL

Marshall Clow : string_view

Casey Carter : std::variant

Richard Smith : constexpr if

Hans Boehm : parallel STL, mais j'ai hâte de l'utiliser

Bjarne Stroustrup : template deduction arguments pour les constructeurs

Q : en avril 2016, j'ai vu la liste de souhaits de Bjarne Stroustrup pour C++ 17. Peu y sont. Que s'est-il passé?

(on blague sur les prédictions dans le monde du logiciel)

Herb Sutter : la liste a essentiellement été couverte, mais plusieurs sous forme TS et implémentés. C'est un immense pas en avant; nous sommes loins des standards « papier seulement » de la fin des années '90.

: a-t-on besoin de graphiques 2D, et si oui, quand?

Herb Sutter : il y a une proposition sur la table et on s'attend à la voir sortir bientôt.

Bjarne Stroustrup : pour la nécessité, ce serait vraiment chouette; le problème est la contribution de firmes sur le comité qui ne parviennent pas à trouver un compromis. Cela dit, Alexander Stepanov nous a donné la STL, alors ces choses-là arrivent.

: comment arriverons-nous à faire progresser le standard plus rapidement?

Chandler Carruth : c'est difficile de définir de nouveaux mécanismes pour un langage. Ça bouge déjà pas mal vite; ce qui nous ralentit, selon moi, est la nature de la bête. Mettre sur pied des groupes d'étude spécialisés et des spécifications techniques nous aide beaucoup.

Bjarne Stroustrup : mon keynote de ce matin répond un peu à la question. Les perspectives sont différentes, la perception du risque et des bénéfices varie selon les individus.

Hans Boehm : un peu des deux selon moi. Il faut des propositions, plusieurs itérations, et une forme de consensus.

Michael Wong : nous avons plus de ressources que nous n'en avions jamais eu. Nous sommes meilleurs que nous ne l'avons jamais été pour atteindre un consensus. Je siège sur d'autres comités, plus petits, et je ne suis pas certain qu'ils sont plus décisifs que nous.

Bjarne Stroustrup : j'aimerais donner un exemple. Certains pensent que le document formel ne devrait contenir que ce qui est vraiment fini et poli. Dans ces cas, ça semble arriver de nulle part, les gens sont nerveux, et il y a des difficultés d'adoption. Nous espérons que les spécifications techniques amènent une connaissance plus concrète et une meilleure adoption.

: qu'attendez-vous des enseignant(e)s qui utilisent C++?

Marshall Clow : à titre de point de départ, je rencontre encore beaucoup de gens qui enseignent C++ 98. Je pense que c'est assez. Arrêtez.

Bjarne Stroustrup : j'en rencontre plusieurs qui attendent avant de parler de vecteurs et d'algorithmes. À mon avis, le point de départ clé devrait être C++ 11, et tant mieux si vous voulez faire plus récent.

Chandler Carruth : vous devriez enseigner ce que vous pouvez compiler, ce que vos outils supportent. Prenez le compilateur de votre choix, mais prenez-en un moderne.

Jon Kalb mentionne le panel de demain midi sur l'enseignement, panel sur lequel je siégerai.

: plusieurs se plaignent d'un manque d'élégance. Est-il temps d'avoir une bibliothèque standard 2.0 ou un « C++ plus », pour repartir à neuf?

Marshall Clow : avec les TS, nous souhaitons entre autres en arriver à une STL v2. Pas au point de tout casser, mais moderniser les pratiques. Ce n'est toutefois pas prêt.

Bjarne Stroustrup : STL v2 sera plus puissante que la STL existante. Elle fera ce que la STL faisait, et même plus. Le code existant fonctionnera encore. Il ne faut pas oublier que la STL est arrivée en 1994; nous avons appris quelques trucs depuis.

Casey Carter se dit d'accord.

Chandler Carruth : je ne trouve pas que le langage est mauvais, et je pense que depuis C++ 11, nos nouveaux mécanismes sont vraiment de meilleure qualité qu'avant.

: je viens de porter le moteur de recherche d'Amazon d'un vieux gcc (v. 4.1) à un gcc plus récent (v. 4.9). Je ne peux pas utiliser C++ 14 encore, mais je gagne de à de temps d'exécution. Ça sauve quelques dizaines de millions de dollars.

Marshall Clow : tout ce qui est std suivi d'un nombre est réservé.

: comment caractériser le C++ moderne?

Bjarne Stroustrup : de meilleurs compilateurs. Une disparition graduelle d'artéfacts du vieux code. Le code devient plus petit, plus propre. Les compilateurs en ont moins à faire, les optimiseurs aussi. J'ai annoncé la GSL l'an passé pour aider les gens à avancer. Je ne sais pas ce que veut dire « C++ moderne », car C++ change chaque jour, mais il est clair pour moi que de meilleurs outils pour moderniser le code font partie de l'équation.

Herb Sutter : en 1998, Andrei Alexandrescu a écrit un livre nommé Modern C++ Design. Ce code n'est plus moderne du tout, le livre étant sorti il y a près de 20 ans. Je vois du vieux code quand je vois beaucoup de delete, pas de auto, des longs noms de types, des boucles for qui utilisent des indices pour parcourir des séquences entières...

Marshall Clow : il y a deux ans, LLVM a décidé d'exiger un compilateur C++ 11 pour être compilé. Dès que ce fut fait, on a eu un tas de propositions de modernisation pour remplacer les trucs « maison » par des outils standards. Notre base de code a été réduite de manière significative.

Bjarne Stroustrup : il est plus facile d'améliorer du code moderne. Il y a moins de code, moins de bruit, plus de signal. Oui, ça va plus vite.

Hans Boehm : c'est aussi plus correct.

Richard Smith : dans du code moderne, RAII est utilisé chaque fois que cela est raisonnable ou possible. Le code est plus petit, plus simple, plus rapide.

Herb Sutter : tous ces pointeurs partagés « maison » qui sont brisés... En particuler, weak_ptr. J'ai dû en écrire un une fois, et j'ai tellement de respect pour les gens qui l'ont implémenté.

: ce matin, on a senti chez Bjarne Stroustrup une légère frustration et on a eu l'impression qu'il aimerait être une sorte de dictateur. Si chacun d'entre vous était un dictateur, de quelle mauvaise décision la communauté aurait-elle pu vous sauver?

Chandler Carruth : toutes!

Herb Sutter : ben, j'ai commencé à aimer les allocateurs...

Bjarne Stroustrup : le pouvoir corrompt...

Herb Sutter : nous faisons tous des erreurs. Brendon Eich, sur le comité de JavaScript, avait une vision très précise des besoins des gens. Les autres membres du comité lui ont apporté des données à l'effet contraire... et il les a écouté. C'est la chose à faire. Peu importe notre rôle, écouter nous sauve les fesses.

Michael Wong : personne ne connaît le langage au complet. Nous nous entraidons.

: pourrait-on standardiser des outils?

Richard Smith : je pense que nous ne serions pas confortables de standardiser ce genre de truc. Les outils existent, sont de bonne qualité, mais outre peut-être la réflexivité...

: alors pourquoi pas une ABI commune?

Chandler Carruth : nous pourrions essayer de standardiser vi, puis emacs... (la salle s'esclaffe) L'idée d'avoir un standard est de pouvoir avoir plusieurs outils. Nous avons une API commune et c'est le langage en tant que tel. Pour la réflexivité, je pense que c'est raisonnable, mais c'est un champ d'application très pointu.

Bjarne Stroustrup : je pense qu'on peut faire un peu mieux pour les outils. Il existe des outils pour les AST mais ça se limite à la syntaxe. On pourrait générer une version non-texte du langage pour faciliter la tâche des outils.

Herb Sutter : un bon aspect de C++ aujourd'hui est que l'on fait de moins en moins d'extensions au langage, ce qui facilite la mise en place d'outils et la portabilité du code. C'est en partie parce que notre langage est meilleur.

: la liste de souhaits de Bjarne Stroustrup ce matin me semblait manquer les multiméthodes ouvertes. Est-ce encore si important de ne pas toucher l'éditeur de liens?

Bjarne Stroustrup : ma liste visait les prochains 18-24 mois. Les multiméthodes ne sont pas dans cet horizon selon moi, et ne sont pas dans mon top 10 même si je les voudrais bien. J'ai aussi hâte qu'on se débarrasse des visiteurs; j'ai hâte au Pattern Matching... Ils ne sont pas sur ma liste car l'horizon me semble plus loin.

: C++ est un grand succès, qui a appris d'autres langages et les a inspirés. Quel regard posez-vous sur ces autres langages?

Richard Smith : nous essayons d'apprendre de ce que font les autres.

Bjarne Stroustrup : le groupe connaît plusieurs autres langages, mais personne ne les connaît tous.

Hans Boehm : pour la concurrence, nous examinons souvent ce que font les autres langages, même si ce n'est pas toujours transposable tel quel dans notre langage.

Michael Wong : nous intégrerons parfois, mais sans copier. En adaptant à nos moeurs.

: quel mécanisme voudriez-vous voir dans le langage demain matin?

Herb Sutter : clang n'a-t-il pas déjà tout implémenté, Richard Smith? (rires!)

Chandler Carruth : au quotidien, les if(decl;cond) et les Structured Bindings me rendent vraiment heureux

Herb Sutter : j'entends plus souvent « mais il y a tant de choses à apprendre! » que « mais je veux ceci et cela! »

Richard Smith : je rejoins Chandler Carruth pour son plaisir. J'ai le plaisir d'être souvent la première personne à tester les nouveaux jouets

Bjarne Stroustrup : je veux les concepts, les modules et les Structured Bindings. Je les ai, mais dans des compilateurs distincts.

Herb Sutter : je regarde Casey Carter et j'ai vraiment hâte d'avoir les intervalles

Michael Wong : j'adore quand les nombreux nouveaux mécanismes tombent en place. C'est magique!

Casey Carter : j'aimerais beaucoup avoir les concepts. Les intervalles fonctionneraient et je pourrais plaire à Herb Sutter

Marshall Clow : j'ai aussi les nouveaux jouets très rapidement, mais les nouveaux types vocabulaires (optional<T>, variant<T0,T1,...>, any) seront, je pense, très populaires

Hans Boehm : j'ai très hâte d'avoir les exécuteurs, pour enfin cesser de demander pardon pour les défauts de std::async

: pourquoi le nom du groupe d'études sur les graphiques 2D a-t-il changé?

Herb Sutter : parce qu'il induisait en erreur.

: comment contribuer?

Marshall Clow : il faut m'écrire.

Bjarne Stroustrup : nous avons tous des adresses courriels et elles sont faciles à trouver.

Michael Wong : on peut aider en soumettant des propositions sur les listes de discussion. Pour pousser un dossier au comité, il faut se présenter ou avoir un champion, et il faut typiquement venir plusieurs fois alors mieux vaut avoir une source de financement. SG14 est un groupe d'étude qui a une forte participation. Nous aurons d'ailleurs une petite rencontre de 30 minutes demain matin.

: dans les systèmes embarqués, les gens pensent qu'il faut utiliser C plutôt que C++. Tristement, le code C++ qu'ils écrivent est du code d'une autre époque, inapproprié.

Jon Kalb : nous avons un Keynote de Dan Saks à ce sujet demain.

Michael Wong : SG14 inclut maintenant aussi les participant(e)s du monde des systèmes embarqués.

Bjarne Stroustrup : il y a beaucoup de mythes sur ce que C++ peut ou ne peut pas faire, dans ce domaine comme ailleurs. Écrire du meilleur code aide. Les gens croient sans vérifier; plusieurs de ces croyances sont simplement fausses.

Jon Kalb : pourquoi réparer C++ avec SG14? C++ n'est pas brisé!

Herb Sutter : de quoi les gens se plaignent-ils?

: la mémoire est petite, quelques centaines de Ko. Les processeurs sont limités. Il nous faut de petits binaires.

Herb Sutter : mercredi, venez à la plénière de Jason Turner qui compilera du C++ 17 pour une machine bien plus petite que celles-là.

Michael Wong : il y a un jeu de perceptions avec lequel nous devons travailler

Bjarne Stroustrup : le terme « template bloat » m'énerve. Il vient de gens qui ne savent pas s'en servir. Les templates éliminent le code qui n'est pas utilisé; ils génèrent moins de code que les équivalents non-génériques!

Marshall Clow : j'ai une anecdote. Récemment, je parlais à une compagnie de matériel qui avait choisi C++ pour de très petits appareils. Vraiment petits...

Chandler Carruth : la question reste à répondre, soit « que pouvons-nous faire? ». Plusieurs croient ce mythe. Aujourd'hui, tu devrais dire que C++ est un menu, vous pouvez utiliser les morceaux qui vous conviennent. Allez-y par étape. Chez LLVM, les gens avaient peur de C++ 11, alors j'ai « éteint » tous les nouveaux mécanismes de ce langage, puis j'ai introduit les mécanismes à la pièce. Sois incrémental, identifiez les problèmes.

Herb Sutter : c'est une approche très constructive. Aussi, presque tout le code C compile tel quel en C++. Par la suite, amuse-toi à remplacer qsort() par std::sort() et vous verrez tout de suite un gain de vitesse. Ensuite, tu y vas selon ce que tu penses que les gens accepteront et tu respectes leur rythme.

Michael Wong : l'endroit pour mener cette discussion est SG14. Viens parler avec nous.

Jon Kalb : il ne reste que peu de temps. Peut-on accélérer?

Chandler Carruth : une réponse par personne, cinq mots maximum.

: je vois plusieurs trucs définis en C++ qui étaient indéfinis ou non-spécifiés en C. Ceci s'améliorera-t-il?

Herb Sutter : on règle certains problèmes, et on demeure conformes à C malgré tout.

: les inclusions textuelles seront remplacées par les modules et nous compilerons plus vite. Aurons-nous droit à une grammaire plus complexe en échange?

Richard Smith : les temps de compilation gonflent pour « remplir » la patience des programmeurs.

: je veux « ploguer » ma présentation, mais pour divulgâcher : LLVM est pas mal, mais pas génial non plus

Chandler Carruth : Patches Welcome

Q : quel paquetage statistique préférez-vous?

Marshall Clow : Arrrrrr

Arthur O'Dwyer : les nouvelles règles de déduction des constructeurs, comment fonctionnent-ils en présence de spécialisations partielles?

Richard Smith : ceux du template primaire

: je veux faire une proposition. Y a-t-il un guide?

Herb Sutter : isocpp.org

: concepts et intervalles, ensemble ou séparément?

Casey Carter : je ne pense pas qu'on peut placer les intervalles sans les concepts. Il faudrait tout réécrire.

Bjarne Stroustrup : les deux, ensemble, bientôt

: corrigerons-nous std::max()?

Marshall Clow : oui

Herb Sutter : pas besoin

Jon Kalb : qu'y a-t-il sur isocpp.org pour nous guider?

Herb Sutter liste 2-3 trucs

On finit à 22 h. Richard Smith joue un morceau de piano alors que nous quittons la salle. Je marche vers l'hôtel, et je réponds aux questions de gens curieux mais qui n'ont pas eu le temps de poser des questions au groupe assemblé sur scène.

Jour 1 20 septembre 2016

Debout àh 30. Je suis un peu fatigué; ça fait quand même trois jours de tourbillon consécutifs, et les deux prochains seront rudes aussi. Aujourd'hui, une pré-rencontre de SG14 s'est ajoutée à l'agenda, versh 15, alors je suis un peu plus pressé que prévu à l'origine. Et je ne suis pas prêt pour ma présentation deh. J'ai bavardé un peu avec Za (ça fait toujours du bien); Skype, c'est imparfait, mais quand on doit voyager, c'est un atout précieux.

Je voulais avoir des chiffres très « à jour » pour ma présentation ce matin alors j'ai refait tous mes tests avant la présentation. J'avais un dossier complet à adjoindre à ma présentation, mais je n'ai pas pu les mettre dans les diapos faute de temps. J'ai créé un dossier Google Drive dans lequel je déposerai le code de test et les chiffres que j'en ai tirés; ça permettra aux gens de jouer avec et de s'amuser.

Je suis arrivé dans la salle où je présentais ce matin. C'était la même grande salle que durant le cours de la fin de semaine, mais elle était bien sûr beaucoup moins pleine (la compétition était forte, c'est le moins qu'on puisse dire : James McNellis et Chandler Carruth présentaient en même temps que moi  ). J'ai quand même eu de la visite : il y avait une entre trente et quarante personnes je dirais, dont Jonathan Caves, Casey Carter, Lisa Lippincott et Dietmar Kühl.

Diapos : https://github.com/CppCon/CppCon2016/blob/master/Presentations/The Exception Situation/The Exception Situation - Patrice Roy - CppCon 2016.pdf

Vidéo (soyez gentils, je ne me fais pas filmer habituellement) : https://www.youtube.com/watch?v=Fno6suiXLPs&feature=youtu.be

Présentation de Patrice Roy

On a commencé àh pile. J'avais un micro et j'étais filmé, alors vous pourrez vous amuser à mes dépens quand ce sera publié. Comme c'est toujours le cas dans de telles circonstances, un bénévole au fond de la salle me montrait des panneaux quand il restait 30, 15, puis 5 minutes. Les gens ici sont toujours très gentils et très courtois avec moi.

The Exception Situation

Je n'ai pas pris de notes sur ma propre présentation, désolé! Mais j'ai fait ce qui était annoncé sur https://cppcon2016.sched.org/event/7nKz/the-exception-situation

Je pense que ça s'est bien passé. J'ai eu des sourires, des questions, quelques échanges intéressants après la présentation, et plusieurs m'ont dit avoir trouvé le tout de bonne qualité. J'ai des des efforts pour garder un débit de parole raisonnable étant donné la présence de la caméra.

Diapos : https://github.com/CppCon/CppCon2016/blob/master/Keynotes/extern C - Talking to C Programmers About C%2B%2B/extern C - Talking to C Programmers About C%2B%2B - Dan Saks - CppCon 2016.pdf

Vidéo : https://www.youtube.com/watch?v=D7Sd8A6_fYU

Keynote de Dan Saks

Jon Kalb prend la scène pour nous inviter à remplir les formulaires pour décrire notre expérience.

Pour le puzzle d'hier, il semble que 96 personnes l'ont réussi. On annonce le gagnant, qui est applaudi. D'ailleurs, j'ai eu quelques commentaires, tous positifs, alors c'est chouette.

Le puzzle de Herb Sutter est disponible aujourd'hui; celui de Jason Turner sera disponible demain.

On présente Dan Saks en des termes élogieux. Il a enseigné par le passé, et le présentateur qui nous l'introduit fait l'éloge de son enseignement.

extern 'C': Talking to C Programmers About C++

Dan Saks se présente. Il a écrit dans plusieurs magazines, a participé à WG21, et est un spécialiste des systèmes embarqués.

Son message de base est : quand il faut persuader quelqu'un, « If you're arguing... you're losing » (j'aime déjà ça!)

Dan Saks : les langages d'intérêt pour la programmation de systèmes embarqués sont...

Dan Saks nous avoue ne jamais avoir construit un système embarqué de calibre industriel en C++. Dans sa carrière, il a surtout dû faire du C.

Quand il a cessé d'écrire dans un magazine de systèmes embarqués, pour quitter en beauté, il a posé la question du langage utilisé au boulot à son lectorat. Deux trucs : plus de C que de C++, et... C est en hausse alors que C++, en deuxième place, est en (légère) baisse. Dan Saks en parle comme un résumé statistique de l'échec de sa carrière (on rit un peu).

Dan Saks dit qu'on peut laisser le marché se charger du problème. Toutefois, cela brime toutes celles et tous ceux qui voudraient utiliser C++ dans le cadre de leur travail.

Dan Saks : définissons le problème. C++ ne croît pas dans un créneau qui devrait être le sien. De plus, de nombreuses programmeuses et de nombreux programmeurs C n'utilisent pas C++ alors que cela les aiderait beaucoup. Nous « savons » que C++ est meilleur que C.

Dan Saks : que faire? En parler... mais peut-être pas comme vous l'imaginez.

Dan Saks relate une anecdote. En 2000, il a écrit un texte à l'effet que représenter des registres par un struct en C serait la meilleure approche dans ce langage. Il explique le modèle qu'il préconisait. Le lectorat a bien réagi et en a demandé plus. Le mois suivant, il a représenté un registre par une class avec la même disposition physique que le struct... et si certains l'ont aimé, plusieurs ont réagi en clamant que la class entraînait une pénalité. Il « savait » que ce n'était pas le cas, alors il a passé plusieurs mois à proposer des mesures pour démontrer l'absence de coût, selon différentes approches et avec trois compilateurs. Son travail a été révisé par plusieurs collègues avant publication et tous semblaient estimer que la méthodologie était solide. Dan Saks dit que la plus grosse différence, tous cas et tous langages confondus, était l'inlining. Cela l'a saisi. C++ était plus rapide dans l'ensemble, même dans les moins bons designs, mais l'inlining était la trouvaille.

Et la réaction du lectorat? « La classe est trop simple ». « C++ encourage la rédaction de code compliqué »... Les chiffres n'ont pas suffi. Pourtant, l'article n'encourageait pas de telles pratiques.

Et la réaction de la communauté de C++? Rien, des criquets. Deux ans plus tard, quelqu'un l'a félicité d'avoir recommencé à écrire sur C++, alors qu'il n'avait jamais arrêté. Il semble que la communauté de C++ ne lisait pas ses textes.

Alors, quoi faire? Le problème n'est pas technique. C'est entre autres un cas de TMM (Too Much Misinformation), mais pas seulement ça. Dan Saks nous raconte qu'il vit en Ohio, même si cela ne paraît pas trop car il est né au New Jersey. Il en parle car son vote a un poids plus lourd qu'ailleurs (ils sont dans le top 10) dans le système américain, ce qui explique qu'ils soient bombardés de publicité. Dan Saks fait remarquer que les voteurs ne font pas vraiment des décisions rationnelles; le vote tend à être émotif. De même, les programmeuses et les programmeurs sont des humain(e)s, malgré la rumeur. Il y aura donc des sciences sociales et de la linguistique dans la présentation.

Dan Saks estime que nous prenons des décisions irrationnelles et que nous les justifions a posteriori. Les gens sont individualistes ou « communautairiens », égalitaires ou hiérarchistes. Ceci définit un spectre qui se projette comme un plan cartésien, et permet d'estimer ce dont les gens ont peur. Le schéma est très intéressant, d'ailleurs. Sur cette base, Dan Saks explique que la communauté C a des craintes différentes de la communauté C++.

Dan Saks parle ensuite de numératie, et mentionne une recherche à l'effet que l'interprétation des données statistiques est affectée par la force du choc encouru par les données qui bousculent leurs a priori. Souvent, reformuler les données de manière mieux choisie influence l'adhésion aux faits. Il cite Jonathan Swift en disant que la raison n'est pas le bon outil pour évacuer une opinion qui n'a jamais fait son nid par voie de raison en premier lieu.

Dan Saks mentionne « I owe you one » et « I'm in your debt ». Il mentionne aussi des formules qui parlent de hauteur (positif) ou de bassesse (négatif). « Tax burden » ou « Tax relief ». « Right to work » peut être encadré par « so-called right to work ». La communauté C est coincée dans un cadre et c'est l'angle d'approche.

Dan Saks mentionne memcpy() pour copier des tableaux, qui peut causer des dégâts si on se goure dans les types des pointeurs. Les programmeuses et les programmeurs C acceptent ces erreurs et le débogage qui vient avec. « Le débogage, c'est le vrai monde » est un cadre de pensée très C. Il faut le remplacer par un autre cadre conceptuel. C'est difficile.

Dan Saks : les tests exposent les bogues. Le débogage les élimine. Le système de types de C++ peut générer les erreurs à la compilation! Il faut un argument émotif, mais ancré dans l'évidence et la raison (question d'éthique).

Dan Saks : où sont les articles scientifiques qui appuient l'affirmation selon laquelle les systèmes de types statiques réduisent les bogues? Il y en a peu. Nous sommes en faute.

Dan Saks : on a aussi le problème que les données factuelles peuvent mener à un accroissement des croyances farfelues, en réaction au choc. Indépendamment de la source, en plus. Il faut faire attention de ne pas empirer la situation.

Dan Saks : la peur de perdre est plus forte que l'appât du gain. Conséquemment, il faut présenter l'argumentaire comme une réduction des risques de perte plutôt que comme un accroissement des gains. Avec une tournure constructive.

Dan Saks : passer de C à C++ demande un effort, et il se peut que nous mettions la barre trop haut. Entre autres, en général, enseigner C++ avec vector, string et iostream est une bonne idée, mais pour migrer de C à C++ ça peut causer un choc. Dan Saks recommande une approche plus incrémentale. Si le fossé est trop grand, il devient moins intéressant de le franchir. Il faut leur parler de ce qu'ils veulent; il faut les écouter. Identifier des objectifs atteignables, et le faire avec eux.

Dan Saks fait quelques suggestions :

Dan Saks : maintenant, on doit décider si c'est un problème qui nous intéresse. Évaluer la part de marché à gagner. Il suggère de commencer par se regarder dans le miroir. Prendre des tournures constructives, par exemple remplacer « Here's why you're wrong » par « How could we verify this? ». C'est bien mieux que les alternatives.

Q : comment approcher des programmeurs pour les aider à s'améliorer?

Dan Saks : en leur demandant ce qu'ils veulent et en les écoutant. Que veulent-ils? Cherchez des points en commun.

Q : comment les intéresser aux templates ou à des mécanismes qui leur sont étrangers?

Dan Saks : on peut faire des liens comme ma fonction de copie de tableaux, qui règle un vrai problème dans leur vie.

Q : on me dit toujours que C++ est difficile et complexe. Que faire?

Dan Saks : on ne peut pas toutes les gagner. C'est vrai que C++ est plus complexe que C.

Q : les abstractions à coût zéro ne sont pas à coût zéro en mode Debug...

Dan Saks : je vais devoir y réfléchir.

(j'ai manqué deux questions)

Q : il y a dix ans, on a eu de la difficulté à bien enseigner les pointeurs intelligents. Ils étaient mal utilisés et étaient lents. Les gens restent accrochés aux mauvais souvenirs...

Dan Saks : c'est très difficile de se départir de mauvaises expériences.

Q : avez-vous une diapositive de ressources et de lectures proposées?

Dan Saks : je peux vous envoyer ça. Écrivez-moi. Je vais peut-être ajouter une diapo, c'est une bonne idée.

(j'ai manqué quelques questions)

Dan Saks : le but des médias sociaux est de renforcer les croyances que nous avons déjà.

(j'ai manqué quelques questions)

Excellent keynote. Ça valait vraiment la peine, et c'était un très bon choix de présentateur. Inspirant. Les questions ont terminé vers 12 h 10.

J'ai répondu à quelques questions de diverses personnes. Un chic type voulait que l'on parle de soir d'éducation, mais je lui ai dit qu'on avait justement un panel sur le sujet à 12 h 30. Il y est allé, d'ailleurs.

Dans le petit peu de temps que nous avions (j'ai eu cinq minutes, vraiment), je me suis acheté un sandwich et un café, puis je suis allé siéger sur le panel portant sur C++ et l'enseignement de la programmation dans les collèges et les universités.

C++ in Colleges Panel

J'ai rapidement englouti mon sandwich, gardé mon biscuit et mon café pour plus tard, et nous avons démarré.

C++ in Colleges Panel

Participant(e)s : Michał Dominiak, Joel Falcou, Hartmut Kaiser, Jackie Kay, Patrick Niedzielski, Vittorio Romeo, Patrice Roy, Brett Searles, Bjarne Stroustrup. Le panel était https://cppcon2016.sched.org/event/8NUc/c-in-colleges-panel mais Bjarne Stroustrup s'est joint à nous.

J'étais sur scène alors je n'ai pas pris de notes, mais en gros, les questions tournent autour de :

On a échangé sur le sujet pendant environ 75 minutes. Je ne pense pas que c'était filmé.

Après le panel, j'ai pris mon biscuit et mon café et je me suis installé pour la présentation de Gor Nishanov, qui est toujours excellent dans ces situations. 

Diapos : https://github.com/CppCon/CppCon2016/blob/master/Presentations/C++ Coroutines - Under The Covers/C++ Coroutines - Under The Covers - Gor Nishanov - CppCon 2016.pdf

Vidéo : https://www.youtube.com/watch?v=bzAbe1VzhKk

Présentation de Gor Nishanov

L'ami Gor Nishanov prend le relais après le panel.

C++ coroutines under the covers: the amazing coroutines disappearing act

Gor Nishanov fait sa présentation avec Visual Studio pour Linux, et fait du « Live Coding » 

Gor Nishanov nous parlera de la magie derrière les coroutines, et les fera disparaître devant nos yeux. Il utilise Ubuntu, clang et LLVM... mais cherche dans Internet avec Bing!

Gor Nishanov commence par générer une séquence infinie de nombres. Presque pas de code. Il combine ensuite deux générateurs, puis converge vers un appel à accumulate().

Gor Nishanov fait ensuite sa magie. Il ouvre le débogueur et nous montre ce qui se passe. Il compile ensuite avec -O2 et enlève l'appel à printf() (il fait return du résultat; dans main()) puis montre les binaires résultants : le compilateur a précompilé le résultat du calcul dans une constante!

Gor Nishanov nous montrera comment les faire disparaître nous aussi.

Gor Nishanov : nous avons examiné quel serait l'impact d'implémenter les coroutines à même l'optimiseur de clang, parce que les optimiseurs sont très bons pour optimiser les fonctions (en général, les coroutines sont des automates, en fait des fonctions avec des points de suspension, et les optimiseurs sont meilleurs avec les fonctions qu'avec les automates). En plus, puisque les coroutines sont à même le coeur de LLVM, on peut même les utiliser dans d'autres langages. Il donne un exemple en C; le code délicat a été enrobé dans des macros.

Gor Nishanov : pour représenter les coroutines, nous devons allouer dynamiquement des états, car nous n'avons pas de pile. Ensuite, nous devons conserver des « points de saut » (Jump Points) pour savoir où revenir lors d'un co_yield. Nous avons aussi besoin de services resume() et destroy() pour les états. Gor Nishanov cite Michelange et parle de la perfection atteinte par la suppression de ce qui est superflu.

Gor Nishanov insère une sélective en début de fonction et des étiquettes pour réaliser un saut vers le point de suspension lors du prochain appel. Le compilateur sait quoi appeler et quand l'appeler. Dans le code généré, clang fait du inlining agressif, et s'adonne même à de la dévirtualisation (de fonctions, pas nécessairement virtuelles). L'optimiseur parvient même à remplacer malloc() par alloca(), et réalise du Heap Elision!

Gor Nishanov : ensuite, on procède à SROA (Scalar Replacement of Aggregates). Les compilateurs aiment (beaucoup!) plus les constantes que les agrégats. Il y a aussi SSA, Static Scalar Assignment, par lequel les variables sont remplacées par des constantes. Une fois tout ça terminé, le code s'élimine de lui-même.

Gor Nishanov : examinons maintenant les coroutines asynchrones. Le travail se passe dans le CGSCC (Call Graph Strongly Connected Components – merci à Félix-Antoine Ouellet qui a eu la gentillesse de me donner les mots que j'avais échappé!) et mène à du inlining. Le CGSCC fait jusqu'à quatre passes (nombre configurable) sur le code en dévirtualisant et en inlinant. En bout de ligne, si les coroutines s'enchaînent entre elles, on finit par ne pas avoir la moindre allocation dynamique de mémoire! (applaudissements de la salle)

: pouvons-nous les utiliser aujourd'hui?

Gor Nishanov : oui, mais si tu crées ton propre Front-End.

Q : quand aura-t-on besoin d'allocation dynamique de mémoire?

Gor Nishanov : quand on passera la coroutine à d'autres fonctions.

Il reste du temps, alors Gor Nishanov enchaîne sur Building a Better Future, pour avoir des futures Zero-Overhead. Il fait un retour sur la trinité future<T>, promise<T> et shared_state<T>. Il démontre que pour en arriver à du Heap Elision, il faut une approche RAII. Il transforme la structure classique d'exécution de futures en quelque chose qui ne dépend pas de la pile.

Alisdair Meredith : cela signifie-t-il que nous aurons une obligation de Tail Call Optimization avec C++ 20?

Gor Nishanov : c'était une présentation hypothétique, mais oui, faudrait la rendre obligatoire dans certaines circonstances. Idem pour Heap Elision.

Jackie Kay : peut-on essayer ces futures?

Gor Nishanov : ça tient sur deux diapos 

Jackie Kay : et comment peut-on annuler une coroutine?

Gor Nishanov : dans le Networking TS, il y a un chic truc qui se nomme io_context et qui peut nous aider. On annulerait le io_context, pas la future.

Une autre excellente présentation : drôle, riche en contenu, pertinente.

Je me déplace vers une autre présentation sur les coroutines; j'ai promis à Kenny Kerr d'aller le saluer, et James McNellis est un chic type.

Diapos : https://github.com/CppCon/CppCon2016/blob/master/Presentations/Putting Coroutines to Work with the Windows Runtime/Putting Coroutines to Work with the Windows Runtime - Kenny Kerr and James McNellis - CppCon 2016.pdf

Vidéo : https://www.youtube.com/watch?v=v0SjumbIips&index=63&list=PLHTh1InhhwT7J5jl4vAhO1WvGHUUFgUQH

Présentation de Kenny Kerr and James McNellis

Salle pas mal remplie. Kenny Kerr est canadien mais a un accent particulier; je suis curieux de savoir d'où il vient.

Putting coroutines to work with the Windows Runtime

Kenny Kerr présente James McNellis et fait un peu de publicité pour Microsoft. James McNellis lui rend la pareille.

James NcNellis dit que nous verrons comment gagner aisément l'accès aux ressources de Windows comme un Thread Pool du système d'exploitation par programmation standard.

James NcNellis montre un exemple avec beaucoup de code, puis un autre, et démontre que le code actuel peut êtrre laborieux.

Kenny Kerr montre qu'avec WinRT, certains nouveaux outils peuvent aider à faire mieux. Il présente l'interface IAsyncOperation<T>. Le code est joli mais n'est pas du C++ standard alors c'est moins près de moi.

Un IAsyncInfo dérive de IInspectable. Ce sont des interfaces COM.

Un IAsyncAction encapsule une tâche de type void. Un IAsyncOperation<T> retourne un T. Il y a aussi des versions avec suffixe WithProgess, donc IAsyncActionWithProgress<P> et IAsyncOperationWithProgress<T,P> P est le type qui permet de suivre le progrès des traitements. L'annulation repose sur un jeton d'annulation, qui est en fait un prédicat testé par l'opération.

Kenny Kerr mentionne qu'il y a quatre adaptateurs de mise en attente dans WinRT.

Je prends un peu moins de notes parce que c'et intéressant, mais moins applicable pour moi. Je peux attester toutefois que le travail fait par cette équipe est très propre. Ils ont des trucs comme hresult_invalid_argument qui est un type représentant une erreur COM.

Truc charmant : co_await 1s; plutôt que thread::sleep_for(). Il y a des raisons techniques pour cela. Leur co_await est spécialisé pour retourner un awaitable quand on lui passe une durée.

Kenny Kerr explique que le Thread Pool de Windows accepte des opérations de type Work, Wait, Timer et I/O. L'exemple de soumission d'une tâche à ce Thread Pool tient sur une diapositive, ce qui est charmant. Une fonction s'exécute sur deux threads à cause d'un co_await, ce qui est plutôt chouette.

: ces trucs sont-ils dans les en-têtes générés aujourd'hui?

Kenny Kerr : oui, ça vient avec la Base Library.

: et si une exception est levée dans un contexte de Background Thread?

Kenny Kerr : c'est Ok, on la ramasse et c'est relevé lors du prochain co_await sur la même coroutine.

James McNellis fait remarquer que le pattern n'est pas limité au Thread Pool de Windows. C'est une simple question de conformité d'interface.

James McNellis présente des cas autres qu'un objet Work.

Ils présentent ensuite des chiffres pour montrer l'efficacité de leurs coroutines en comparaison avec des std::future. Évidemment, on s'en doutait, leur implémentation est extrêmement rapide.

: disponible quand?

Kenny Kerr : dans quelques semaines.

Gor Nishanov : si on vous le demande gentiment, pourrait-on ajouter un IAsyncAction... qui testerait tout seul pour les demandes d'annulation?

Kenny Kerr : oui; pour toi, on ferait n'importe quoi.

: si une fonction a plusieurs co_await, quelle est la différence avec plusieurs appels à .get()?

James McNellis : ça bloque à chaque fois alors, s'il y a des entrées / sorties, un thread est pris pour ne rien faire.

Gor Nishanov a posé quelques autres questions croustillantes que je n'ai pas notées. J'ai salué quelques personnes, en particulier Kenny Kerr car je lui avait promis, puis je suis allé prendre une bouchée (des tranches de saucisses, des légumes sautés, un peu de moutarde et de pain, de même qu'une bouteille d'eau) et je suis allé m'installer pour la présentation de Stephan T. Lavavej qui, normalement, devrait être très populaire.

Diapos : https://github.com/CppCon/CppCon2016/blob/master/Presentations/tuple, What's New, And How It Works/tuple, What's New, And How It Works - Stephan T. Lavavej - CppCon 2016.pdf

Vidéo : https://www.youtube.com/watch?v=JhgWFYfdIho&feature=youtu.be

Présentation de Stephan T. Lavavej

Il se peut que mon rapport de cette présentation soit incomplet, car Stephan T. Lavavej est sûrement l'orateur capable de placer le plus de contenu dans un espace-temps limité (suivi de près par Alisdair Meredith).

tuple: What's New, And How It Works

Stephan T. Lavavej entretient la STL et nous parlera de tuple. Il a des numéros de page en haut à droite (avec une flèche pour nous montrer où elles sont  ). Tout ce qu'il présentera (sauf ce qui est nouveau avec C++ 17 depuis Oulu) est disponible dans Visual Studio 2015 Update 3.

Stephan T. Lavavej explique la prononciation de tuple et on l'applaudit en riant.

Stephan T. Lavavej présente des exemples

Retourner plusieurs valeurs d'une fonction (avec les codes 'NCC', 1701 et 'D'  )

Créer des structures de données (vector<tuple>, map<string,tuple>, etc.). On peut prendre des struct avec attributs nommés, mais des fois ça ne vaut pas la peine

Implémenter la comparaison lexicographique (avec tie()) pour un Point{int x,y,z;};

On peut créer une pair : pair<vector<int>,vector<int>> p(piecewise_construct, forward_as_tuple(), forward_as_tuple(3,1729)); ce qui est utile pour map entre autres

On a des attributs d'instance variadiques. tuple est le struct le plus paresseux du monde. Stephan T. Lavavej présente les forces et les faiblesses de ce type. Travailler avec des attributes variadiques devient intéressant depuis C++ 14 (c'était moche avec C++ 11)

Stephan T. Lavavej passe aux caractéristiques de tuple : make_tuple(), tie(), forward_as_tuple(), tuple_cat(), et il donne au passage quelques trucs de sain usage. Entre autres, ne nommez pas explicitement les types de make_tuple(); laissez le compilateur faire ce qu'il fait bien. Aussi, forward_as_tuple() peut générer des rvalue references alors c'est utile pour transférer, pas pour entreposer.

Stephan T. Lavavej rappelle que tie() peut être utilisé pour fins d'affectation déstructurante, en combinaison avec ignore si des éléments sont sans intérêt. Il se dit craintif de tuple sur des références : vector<T&> est interdit; vector<tuple<T&>> passe mais est vilain. C'est un trou dans le système de types.

Stephan T. Lavavej parle des traits de tuple : tuple_size<Tup>::value, tuple_element<I,Tup>::type, qui fonctionnent aussi sur des pair et des array. Il recommande d'appliquer remove_reference aux T&&

Stephan T. Lavavej donne un exemple de get_back<Tup>(Tup &&tup) et utilise decltype(auto) comme type de retour.

Stephan T. Lavavej présente get<I>(Tup) qui propage le côté lvalue / rvalue ref et const. Il se trouve que get<I>(tup) est une fonction globale pour éviter, dans un contexte générique, d'être pris pour écrire t.template get<0>()

Stephan T. Lavavej : « when you can repeatedly name something, then it's an lvalue »

Stephan T. Lavavej passe aux caractéristiques de tuple avec C++ 14

Stephan T. Lavavej : get<T>() qui permet d'accéder à un élément par son type si ce n'est pas ambigu. C'est constexpr et ça propage const, & et &&. Ça existe pour pair, et ce serait un peu nono pour array

Stephan T. Lavavej : integer_sequence, make_integer_sequence, index_sequence, make_index_sequence et index_sequence_for<Ts...>

Stephan T. Lavavej : make_integer_sequence peut se faire à la compilation par la bibliothèque, mais pour aller plus vite et prendre moins de mémoire, ils ont un Compiler Hook.

Stephan T. Lavavej montre comment obtenir une classe avec des attributs variadiques en passant par des tuple.Il fait un MiniBind avec ça. Il recommande de ne pas faire de travail récursif avec tuple.

Stephan T. Lavavej passe à C++ 17 : apply(); make_from_tuple(); opérateurs logiques conjunction, disjunction et negation.

Stephan T. Lavavej montre que apply() remplace aisément MiniBind.

Stephan T. Lavavej : make_from_tuple relaie les éléments d'un tuple en paramètre à un constructeur

Stephan T. Lavavej : conjunction et ses amis sont respectueux des short-circuit, ce qui épargne des types

Stephan T. Lavavej dit que pair et tuple ont tous deux des constructeurs de relais conditionnellement explicites. C'est nouveau avec C++ 17, il faut se préoccuper de explicit sur des constructeurs à deux paramètres et plus!

Stephan T. Lavavej fait le tour des constructeurs de tuple. Il y en a beaucoup!

Stephan T. Lavavej parle de son implémentation de EXPLICIT. Super intéressant mais je m'endors...

Stephan T. Lavavej fait un bref tour d'horizon des derniers détails. Entre autres, mieux vaut utilier enable_if sur ses types pour contrôler les risques

Alisdair Meredith : comment conjunction et amis fonctionne-t-il avec les Fold Expressions?

Stephan T. Lavavej : on ne le supporte pas encore alors ça n'existe pas pour moi.

J'ai manqué les autres questions

Il est 17 h 45 et je m'endors. Les derniers jours me sont « rentrés dedans » cet après-midi. J'ai quelques offres pour aller souper (la gang d'Ubisoft, les amis Gabriel Aubut-Lussier et Kevin Cadieux, une espèce d'événement social d'une firme qui fait du recrutement ici et où vont des gens qui veulent me parler d'éducation) mais je tire de la patte. Je marche à l'hôtel déposer mes trucs et je pars vers l'épicerie me chercher de la salade de pâtes, des carottes et du hummus... mais je me suis perdu, signe que je suis fatigué (perdu, faut le dire vite : je sais où je suis mais je ne retrouve pas l'épicerie, qui est pourtant tout près). Je demande de l'aide à quelques personnes, dont certaines avec des GPS, et toutes m'envoient (malgré leur bonne volonté) dans des directions farfelues. Je finis par me tanner, revenir à l'hôtel, prendre une petite carte et y aller (c'est vraiment tout près).

Je voulais travailler un peu sur mon doctorat mais je n'ai plus d'énergie; j'ai parlé avec mon amoureuse Za, avec ma grande Marguerite qui était passé par la maison (ça fait toujours du bien de parler aux flos!) puis je me suis couché.

Jour 2 21 septembre 2016

Petite jasette matinale avec Za, douche, examen rapide des vêtements qu'il me reste pour voir si je vais me rendre jusqu'au voyage du retour ou si je vais devoir faire un peu de lessive. Aujourd'hui, c'est la rencontre formelle de SG14, une grosse journée qui débute àh 30 et qui finit quand on a fini, mais avec une pause pour la présentation de Jason Turner qui nous intéresse tous.

J'arrive le premier dans la salle de la rencontre de SG14 mais plusieurs suivent quelques minutes plus tard. JF Bastien me présente une extension de chrome qui génère des chats animés à chaque nouvelle ouverture d'onglet (le Tabby Cats Club), extension que j'envoie à ma chic maman Lucille dans les moments qui suivent (dans l'espoir que cela fonctionne sur sa tablette, même si au fond je n'en sais strictement rien). Michael Wong arrive versh 27 avec Sean Middleditch, alors on pourra débuter à l'heure.

SG14 partie I

Michael Wong se présente, explique les « règles du jeu ». Tour de table pour se présenter; une salle extrêmement intéressante, avec des gens de plusieurs horizons incluant Dreamworks, Facebook, plusieurs gens qui font de l'imagerie, de la finance, des jeux (dont le développeur principal de World of Warcraft), des systèmes embarqués, des consoles de jeu, de la messagerie, des gens intéresés par la manipulation des nombres, les systèmes hétérogènes, la capture de mouvements, etc. Michael Wong souhaite une discussion ouverte en après-midi sur les préoccupations des gens de divers horizons.

Michael Wong explique l'intérêt de SG14 et son rôle dans l'évolution du langage. Il propose qu'on tienne des minutes minimalistes, limitées aux décisions prises. Brittany Friedman prendra des minutes minimalistes sur le Wiki.

Michael Wong mentionne le panel sur la compression de jeudi soir, où Guy Davidson siègera. On aimerait avoir plus de représentants.

On examine la logistique de la journée, car plusieurs offrent des conférences concurremment avec la rencontre du groupe.

Michael Wong offre un survol bref de C++ 17, et explique la procédure à partir de maintenant, qui mènera les pays à commenter et à critiquer des éléments du texte proposé. L'objectif est d'accroître le consensus; ce qui réduit le consensus nuit au processus de standardisation.

Michael Wong mentionne ensuite le GitHub, qui est devenu un GitHub organisationnel (il était à l'origine sous la gouverne de Guy Davidson).

On se met en marche pour une phase de triage des dossiers. On traitera des dossiers suivants :

On traitera peut-être des dossiers suivants :

Informellement, on discutera de certains dossiers :

Guy Davidson demande ce qui rend une proposition acceptable pour la bibliothèque. Dietmar Kühl parle du rasoir d'Occam : faut que tout le monde en ait besoin, ou encore faut qu'une proportion « raisonnable » de la communauté en ait besoin, et faut que ce soit « raisonnablement » difficile à faire

La liste de dossier à traiter est trop longue; faudra filtrer. Michael Wong fait du classement de dossier en collaboration avec les gens de la salle pour être certain que l'on n'ait pas de conflits d'horaires.

À côté de moi, JF Bastien s'amuse à implémenter un truc qui se comporte comme memory_order_consume 

Intrusive Smart Pointers – Isabella Muerte

Isabella Muerte cherche une rétroaction rapide sur retain_ptr<T,R>, une sorte de pointeur qui couvrirait ceux de COM ou d'Objective-C, pour faciliter l'interface avec les (nombreuses) technologies existantes qui entreposent le compteur à même l'objet pris en charge. Le T est le type pointé, et le R est une fonction de libération. L'implémentation repose sur <type_traits> et est une pure extension à la bibliothèque existante. C'est inspiré du type intrusive_ptr de Boost (par Peter Dimov) mais avec quelques divergences de design.

Les use counts sont exposés sous forme de long en conformité avec shared_ptr<T>. Des traits sont exposés sur la base du type T pour déduire quoi faire pour incrémenter, décrémenter et détruire le pointé. Ce trait expose des méthodes de classe qui, par défaut, sont supprimées.

Paul E. McKenney : tu ne veux pas utiliser ça avec un pointeur brut tout simple, n'est-ce pas?

Isabella Muerte : exact

Q : l'as-tu essayé avec C++/ CLI ou Java, pour interagir avec un moteur de collecte d'ordures?

Isabella Muerte : non, c'est pas approprié. Ça prendrait une autre approche (unique_ptr<T> avec un Custom Deleter par exemple)

: pourquoi pas shared_ptr avec un allocateur maison?

Isabella Muerte : on aurait une incohérence des use counts.

Hans Boehm pose quelques questions de synchronisation.

Michael Wong prend un vote. Ça semble être fortement en faveur (cool!). Du beau boulot.

inplace_function – Nicolas Fleury

Nicolas Fleury décrit sa proposition, qui tient à donner le contrôle sur la taille du tampon de mémoire interne dans lequel on pourrait placer l'objet appelable, à ceci près qu'il souhaite que le code qui solliciterait une taille trop grande ne compilerait pas (plutôt que de passer par de l'allocation dynamique de mémoire). Nicolas Fleury suggère qu'on aligne le nom officiel avec celui qui sera éventuellement adopté pour ce qui est présentement inline_vector, par souci d'uniformité.

Nicolas Fleury dit qu'on peut affecter une inplace_function à une std::function mais pas l'inverse, pour maintenir les garanties et l'intérêt du type.

JF Bastien : l'alignement indiqué est-il celui du tampon interne?

Nicolas Fleury : oui

JF Bastien : au fond, c'est pratiquement la même chose que std::function; outre le nommage, on pourrait se servir de ceci pour raffiner std::function

Nicolas Fleury : la différence est qu'on ne veut pas que ça compile si la taille dépasse la capacité.

JF Bastien : on pourrait donc utiliser un allocateur qui abort() lors d'un débordement (j'en parle avec lui ensuite; on souhaite ici une erreur de compilation, pas une erreur à l'exécution, et on vient de retirer le support des allocateurs dans std::function avec C++ 17 alors il y a un besoin concret ici selon moi).

: pourrait-on simplement simplement ajouter un static_assert dans la bibliothèque et garder std::function?

Nicolas Fleury : on ne veut pas briser l'ABI de std::function. Selon nous, deux types distincts est le chemin à suivre. Sean Middleditch ajoute qu'il y a de la résistance à imposer SSO dans std::function (c'est optionnel pour le moment).

Michael Wong prend un vote. Ça semble être fortement en faveur. Bravo Nico!

On arrête vers 10 h 8 pour aller à la présentation de Jason Turner.

Diapos : https://github.com/CppCon/CppCon2016/blob/master/Demos/Rich Code For Tiny Machines/Rich Code For Tiny Machines - Jason Turner - CppCon 2016.pptx

Vidéo : https://www.youtube.com/watch?v=zBkNBP00wJE

Présentation de Jason Turner

Le modèle fruits + yogourt + café se poursuit, mais je trouve ça très correct. Je ne l'ai pas écrit encore je pense, mais chaque matin, nous sommes accueillis par un groupe blues avant le keynote et cela met une ambiance sympathique en place.

Ce matin, Jason Turner ne fait pas tant un keynote qu'une démonstration... mais une démonstration franchement sympathique. Nous avons tous très hâte de voir comment il va s'y prendre.

Jon Kalb prend la scène. Il invite les gens à voter pour les posters. Le puzzle de Jason Turner est proposé aujourd'hui. Demain, nous ajoutons une présentation sur la compression et un panel sur le même sujet. Une séance de Lightning Talks a été ajoutée, et une rencontre des planificateurs (dont moi) aura lieu jeudi soir.

C'est Rob Irving, co-animateur de Jason Turner sur CppCast, qui fait les présentations.

Rich Code For Tiny Machines: A Simple Commodore 64 Game In C++ 17

Jason Turner sonde l'audience pour savoir en fonction de quelles plateformes les gens présents ici développent. Pendant qu'on vote, son ordinateur redémarre (ouch!). À la blague, Marshall Clow lui suggère d'utiliser le projecteur du Commodore 64. Environ des gens programment sur des microcontrôleurs. Très peu sont restreints à des processeurs avec arithmétique 16 bits.

Jason Turner dit que son objectif est de programmer en C++ 17 sur un très vieil appareil et d'avoir du plaisir ce faisant. Sa machine redémarre et Jason Turner se dit heureux de ne pas avoir fait « redémarre et installe ». Il dit « Merci Microsoft » et quelqu'un dans la salle répond « y a pas de quoi! »  . Jason Turner invite tout le monde à prendre connaissance de Matt Godbolt et de son chic outil.

Jason Turner parle de son amour pour le bon vieux Commodore 64 et de son plan de s'amuser avec lui maintenant qu'il est assez vieux pour comprendre ce qu'un ordinateur fait. Il montre des équivalents de code assembleur sur les processeurs contemporains et sur un 6502. Il trace aussi un historique de cet ordinateur et en décrit les spécifications techniques. Entre autres, la mémoire requise pour le code généré dans sa démo entre entièrement en Cache L1 d'un ordinateur contemporain.

Jason Turner nous montre le jeu visé (un clone du vénérable pong).

Jason Turner nous montre l'architecture d'un ordinateur, avec un schéma à quatre morceaux : CPU, RAM, périphériques, bus. La salle éclate de rire.

Jason Turner parle des Memory-Mapped Devices. C'est plutôt pratique dans ce cas-ci. Il fait une démonstration avec des reinterpret_cast et du code assembleur.

Jason Turner montre qu'il peut aisément écrire des fonctions sans le moindre « surcoût ». On a des reinterpret_cast et des volatile par la force des choses (sans volatile, il a une boucle infinie)

Jason Turner passe ensuite à une description de la mémoire vidéo. Il fait de petits miracles avec constexpr et génère à chaque coup du code pratiquement sans le moindre « surcoût ».

Jason Turner fait un petit tour des couleurs supportées par un Commodre 64. Les conversions de valeurs RGB se font à coût zéro : il cherche à trouver la couleur la plus proche d'une couleur de référence avec std::min_element(). À un moment, il y a beaucoup de code généré, puis il marque un tableau const et tout disparaît.

Jason Turner dit que son code n'exige que C++ 14, mais qu'il est beaucoup plus joli encore avec C++ 17. Il profite du fait que clang en supporte une bonne partie, et utilise la bibliothèque standard de gcc qui sert bien ses objectifs.

Jason Turner mentionne RAII et suggère qu'on y pense comme un atout d'un point de vue de déterminisme. Le code généré est microscopique et va extrêmement rapidement alors il insère des marqueurs pour contrôler l'affichage. Avec cette approche, il s'en sort à coût zéro.

Jason Turner dit que le Commodore 64 a huit Sprites matériels pixels chacun. Les Sprites matériels sont de simples bitmaps. Il utilise un template variadique nommé make_sprite() pour les générer, et affiche les pixels semi-récursivement fois (le est la fonction qui orchestre les appels). Le compilateur génère la table de pixels pour nous. Il génère la « balle » (une binette colorée) et la « palette ». Il utiliser if constexpr pour générer les deux d'une même fonction en filtrant les effets requis.

Jason Turner rappelle que le processeur du Commodore 64 est huit bits, alors il a limité son espace de jeu à 255 pixels de large. Il fait une prise en charge du Joystick. Lors de collisions, il profite de l'affectation déstructurante pour extraire efficacement les diverses données retournées. Au total, le jeu se compile à 83 instructions C++ si on escamote le Boilerplate, et à 419 instructions machines 6502. Un total de 1.3 Ko. Il joue devant nous avec un véritable Commodore 64 et un véritable Joystick Atari. On a même réussi à projeter (de peine et de misère) sur grand écran. Herb Sutter vient l'aider pour la démo. Il y a de petits glitches de physique mais ça marche!

Disons qu'il y a eu beaucoup d'applaudissements ce matin, et qu'on a un argument massue pour ceux qui pensent que C++ n'est pas approprié pour un système embarqué.

Jason Turner dit que son utilisation de mémoire vive allouée dynamiquement est nulle. Il a utilisé des objets, des méthodes d'instance, des λ des templates variadiques, des algorithmes standards, etc. sans le moindre « surcoût »

: le compilateur déduit-il constexpr de const?

Jason Turner : pas ici.

Q : peut-on optimiser for_each_arg()?

Jason Turner : oui

Q : le Commodore 64 supporte-t-il les exceptions?

Jason Turner : j'ai pas essayé, je n'en avais pas besoin.

Q : as-tu un truc pour faire static_assert sur la taille du binaire?

Jason Turner : non, mais si tu évites l'allocation dynamique de mémoire, le code généré reste pas mal petit.

Q : voir le code généré post-optimisation est stupéfiant. As-tu comparé avec une version écrite à la main?

Jason Turner : non, mais je suis sûr qu'une fois la vidéo sur YouTube, je vais recevoir des courriels pour me l'expliquer.

Herb Sutter : je pense que ton utilisation de mémoire est encore meilleure que zéro, car tu peux tirer profit du matériel ici.

Q : adapter le désassembleur pour 6502 a-t-il été long?

Jason Turner : environ une semaine à temps complet.

Quelques questions suivent sur l'effort investi, les raisons, le temps de développement...

Applaudissements bien mérités. Jason Turner termine vers 11 h 54. Je vais aller manger rapidement avec Gabriel Aubut-Lussier et Kevin Cadieux, car je dois revenir travailler sur place rapidement (rappel de l'Université pour un document un peu pressant). Brittany Friedman s'est jointe à nous. En quittant la grande salle, je croise Dan Saks et j'en profite pour lui dire à quel point j'ai aimé son keynote d'hier.

Nous sommes allés dans une mini cafétéria, pour qu'il y ait des options végétariennes, question de bavarder un peu même si je suis pressé. Brittany Friedman et moi avons échangé entre autres sur Unreal Engine, et j'aurai des trucs à raconter à mes amis Vincent Echelard et Claude Cardinal au retour du voyage.

SG14 partie III

Je bavarde un peu avec mon ami Billy Baker en attendant le début des travaux (et en préparant une formation sur C++ 14 et C++ 17 pour une boîte de jeu montréalaise, parce qu'il faut quelque chose pour vendredi). Il me montre les diapos de sa présentation sur les éléments du langage C++ qui disparaissent avec C++ 17, et elles sont pleine de zombies souriants...

Une de mes étudiantes de la fin de semaine a apporté des macarons pour la pause de milieu d'après-midi. C'est gentil!

fixed_point Library – John McFarlane

John McFarlane revient sur sa proposition d'un type standard fixed_point. Il expose les raisons pour ce type et les irritants qu'il résout.

Alisdair Meredith demande si les bits dans la notation sont binaires ou décimaux. John McFarlane dit que c'est binaire, car les programmeurs qui utilisent des nombres à virgule fixe pensent de cette manière.

John McFarlane présente une technique d'« élastication », pour des elastic_integer<N,T>, qui se souviennent des bits réellement utilisés et de la représentation d'origine. Ce type facilite certaines conversions et réduit les risques de perte de données.

: comment fixed_point interagit-il avec les fonctions de <cmath>?

John McFarlane : c'est un autre dossier, mais il faudrait écrire de nouvelles versions, c'est clair. J'essaie de garder la portée de la proposition sous contrôle.

: pour nous, une des clés est l'interopérabilité avec les types primitifs...

John McFarlane : ce type supporte le transtypage de et vers les types numériques primitifs, qu'ils soient entiers ou à virgule flottante.

Alisdair Meredith : je crains certaines conversions lossy. Peut-être aura-t-on besoin d'un peu de support de niveau langage?

John McFarlane : les techniques de Louis Dionne peuvent nous guider ici. Pour le moment, je suis un peu débordé pour explorer cette question moi-même.

Arthur O'Dwyer : j'ai l'impression que la proposition est correcte telle quelle (un échange technique à plusieurs s'ensuit)

: je ne suis pas certain de comprendre ce qui motive l'idée d'archétype dans la représentation choisie.

John McFarlane : c'est pour guider le choix d'une famille de types lorsque les précisions impliquées débordent l'ensemble des possibles pour la représentation de base.

Scott Wardle pose quelques questions sur la génération des types élastiques. C'est plutôt technique. Sunil Srivastava pose aussi des questions en ce sens.

Alisdair Meredith : fixed_point supporte-t-il le zéro négatif?

John McFarlane : ça dépend du type entier qui sert de représentation, donc c'est non pour les entiers primitifs.

Paul E. McKenney fait une blague sur les ordinateurs trinaires et on rit un peu.

Guy Davidson demande si on peut avoir plus d'exemples. John McFarlane dit qu'il y en a sur une page GitHub. Michael Wong suggère d'en ajouter dans la proposition aussi.

John McFarlane souhaite savoir quoi faire pour que ça avance un peu. Michael Wong fait remarquer que SG6 ne se rencontre pas souvent.

Alisdair Meredith : demande si on peut instancier des fixed_point<std::complex<T>>. John McFarlane va explorer. On parle aussi de spécialiser make_signed et make_unsigned pour les fixed_point (c'est illégal de spécialiser ces trucs du côté client, contrairement à numeric_limits qu'on peut spécialiser au besoin).

Patrice Roy suggère qu'on propose à SG6 de prendre le relais pour fixed_point s'ils peinent à se réunir, étant donné que ce type est un outil dont l'industrie a bien besoin.

John McFarlane présente ensuite width<T> et set_width<T> qui permettent de jongler plus aisément avec l'élasticité des entiers. Alisdair Meredith fait remarquer qu'il faudra savoir si c'est un concept général, destiné à <type_traits> mais sous interdit de spécialisation par le code client, ou si c'est spécifique à <fixed_point>. John McFarlane veut y réfléchir mais visait les types entiers en général. Il pense qu'on pourrait enrichir numeric_limits<T> de manière générale.

Michael Wong passe un vote. C'est favorable.

Rings – Guy Davidson

Guy Davidson explique les changements. Elle n'est pas concurrente mais est multiples producteurs / multiples consommateurs.

Alisdair Meredith : paie-t-on un prix pour le cas monothread?

Guy Davidson : oui, mais parce que le cas à un seul producteur / un seul consommateur est trivial.

Guy Davidson explique que le type a un popper pour déterminer quoi faire avec la mémoire lors d'un pop.

: je pourrais m'en servir sans concurrence, alors peut-être pourrait-on faire deux versions?

Guy Davidson : je présume

Sean Middleditch : est-ce exception-safe?

Guy Davidson : ... (on rit un peu)

John McFarlane : est-ce que try_push bloque par défaut?

Guy Davidson : oui

Guy Davidson demande si un pusher, pour accompagner le popper, serait une bonne idée. Un membre de l'audience dit que dans son entreprise, c'est la décision à prendre lors d'une file pleine qui est difficile à prendre, et qui pourrait être paramétrique.

Alisdair Meredith : pour répondre à cette question, j'aimerais voir un insert_iterator sur ce type. J'aurais les idées plus claires.

Michael Wong donne une pause de sept minutes. Les macarons sont délicieux, mais la pause est courte. Café, petits bonjours à Walter E. Brown, Eric Niebler et Vittorio Romeo, puis on recommence.

Hazard Pointers – Maged M. Michael

Maged M. Michael propose une technique intrusive (par voie de parent, ça semble une approche CRTP de ce que je peux en comprendre). La classe hazptr_owner peut lever une exception intialement quand elle cherche à allouer un Hazard Pointer, et c'est le seul risque de levée d'exception dans son implémentation.

Alisdair Meredith demande si on doit avoir une cache_policy par type ou si on peut sortir ce type du hazptr. Patrice Roy suggère de le sortir et de faire le couplage de l'extérieur pour générer moins de types. Ça prend quelques itérations mais on finit par se comprendre et Maged M. Michael semble d'accord avec l'idée.

Maged M. Michael envisage une technique semblable à enable_shared_from_this pour ce type mais se demande si c'est une bonne idée.

Eric Fiselier fait remarquer que les demandeurs de retirer std::function<void(T*)> le font pour éviter des allocations, mais ce type n'allouera pas pour un pointeur de fonction. Paul E. McKenney craint des cas d'allocations qu'il mentionne mais qui m'ont échappé. Sean Middleditch mentionne inplace_function de ce matin, qui n'allouera jamais. Quelqu'un argumente une forme d'homogénéité avec unique_ptr.

Eric Fiselier dit qu'on peut avoir un point de personnalisation et un trait principal. Il suggère de garder std::function comme type par défaut et de permettre la personnalisation par un trait.

Michael Wong suggère qu'on ne vote pas. On a la rétroaction souhaitée.

RCU Paul E. McKenney

Paul E. McKenney fait le tour rapide de la proposition.

Alisdair Meredith demande si on peut appliquer le suivi des dépendances sur un entier. Lui et Paul E. McKenney échangent sur les manoeuvres de marquage de bits que cela rend possible. Paul E. McKenney dit qu'il préfère que l'on se limite à des pointeurs, et que modifier les bits d'un pointeur nous donne du comportement indéfini.

Paul E. McKenney présente depending_ptr<T> et met le blâme sur JF Bastien, disant que lui-même est un programmeur C et n'utilise pas de templates. On rit un peu.

La présentation est complexe et va très, très vite. RCU est un sujet important, mais pas un truc de novices, et on a l'expert planétaire devant nous.

Patrice Roy fait remarquer la présence d'opérateurs d'arithmétique sur des pointeurs dans depending_ptr<T> et demande si c'est volontaire, du fait que tous les exemples qu'il a vus manipulaient des listes d'enregistrements. Paul E. McKenney dit que c'est bien le cas. Il y a d'ailleurs d'autres cas d'arithmétique de pointeurs dans son document.

Vittorio Romeo se demande si on pourrait paramétrer le pointeur de rappel par un trait, un peu comme ça a été suggéré pour hazptr. Paul E. McKenney penche pour une situation d'héritage, mais je pense qu'il fait déjà des culbutes pour plaire à la communauté C++ alors ça lui semble un peu... vaporeux. Arthur O'Dwyer s'offre mais avoue ne pas savoir grand-chose sur RCU. C'est le cas de plusieurs dans la salle. Il y a quelques offres du genre.

Brève pause à 16 h 23. Il y a des crudités et des mini empanadas, ce qui est tout à fait correct.

Thread Constructor Attributes – Vicente J. Botet Escribá (présenté par Patrice Roy)

Patrice Roy présente les idées dont Vicente J. Botet Escribá et Patrice Roy ont discuté au cours des dernières semaines sur la base de la proposition de Vicente J. Botet Escribá .

Il n'y a pas eu d'opposition, quelques suggestions que j'ai suggéré de me faire suivre par écrit, alors on pourra progresser.

Intrusive Containers – Hal Finkel (présenté par Guy Davidson)

Inspiré par Boost.Intrusive, mais un peu plus simple, c'est un ensemble de conteneurs intrusifs qui peuvent être avantageux dans certains cas. Une intrusive_XXX peut entreposer des instances de classes dérivées de intrusive_XXX_element

: a-t-on des spécifications sur la disposition en mémoire des éléments?

Eric Fiselier fait remarquer qu'il se peut que le design actuel, basé sur de l'héritage, introduise du padding et donne une disposition suboptimale en mémoire.

Gor Nishanov dit que certains conteneurs intrusifs implémentent des sémantiques de transfert de responsabilité, ce qui peut rendre les opérations plus transparentes.

Patrice Roy suggère de remplacer le recours à une classe de base par un « wrapper » générique qui pourrait être paramétré sur le type des objets à entreposer.

Attributes for Likely and Unlikely Branches – Clay Trychta

Clay Trychta : propose de standardiser les pratiques pour inciter le compilateur à générer du code sur la base de la probabilité qu'un chemin soit pris ou non dans un programme. Il suggère [[likely]] et [[unlikely]].

Clay Trychta mentionne qu'il y a d'autres cas aussi, soit ceux où la branche improbable est celle qui doit aller très rapidement lorsqu'un problème survient.

Matt P. Dziubinski décrit le comportement de gcc dans ces cas.

Eric Fiselier dit que la portée de la proposition n'est pas claire. Il existe des manières non-portables de faire ce qui est proposé; si on va plus loin, ça peut déraper.

Arthur O'Dwyer dit qu'il pense qu'on devrait statuer sur une syntaxe d'abord. Quelqu'un ajoute que tout là-dedans est charmant mais qu'il commencerait par [[likely]] et [[unlikely]].

Dietmar Kühl parle de la résistance des auteurs de compilateurs quant aux annotations pour fins d'optimisation.

Staffan Tjernstrom fait remarquer que dans certains cas, l'optimisation à l'édition des liens donne la mauvaise réponse.

Nicolas Guillemot dit que certaines annotations peuvent nuire au code généré, mais que ces annotations permettraient des tests rapides. Dietmar Kühl dit qu'on n'a pas besoin d'annotation standardisées pour ça. Il y a divergence d'opinion ici. Quelqu'un dit préférer [[hot_path]] et [[cold_path]], ou encore [[critical_path]] pour faciliter le maintien dans la Cache d'instructions d'un chemin même s'il semble improbable.

Matt P. Dziubinski dit que le problème est que PGO (Profile-Guided Optimization) est trop lent pour générer du code de production, mais qu'il existe FDO (Feedback-Driven Optimization) qui travaille pas instrumentation.

Sean Middleditch commente à l'effet que peu importe ce que les vendeurs de compilateurs pensent, ces fonctionnalités sont nécessaires pour la communauté de SG14. Les programmes ne sont parfois tout simplement pas corrects sans ces optimisations, au sens où ils ne remplissent pas leur mandat.

Michael Wong demande si on continue une trentaine de minutes encore. Il est 17 h 30 et notre rencontre arrive à terme, mais on fait le choix de rester jusqu'à 18 h. Matthew Bentley prend le plancher.

segmented_stack – Matthew Bentley

Matthew Bentley critique std::stack en tant qu'adaptateur pour des conteneurs, du fait que le substrat par défaut est std::deque et que certaines implémentations sont suboptimales. Son implémentation intiale était naïve et présentait segmented_stack comme un conteneur mais elle n'exposait pas d'itérateurs et ne rejoignait, par le fait-même, pas le concept de conteneur.

Alisdair Meredith suggère de ne pas trop se stresser avec le « concept de conteneur » et on ajustera sur adoption.

Matthew Bentley pense qu'une pile représentée par un adaptateur est suboptimal. On peut utiliser vector comme substrat pour std::stack mais selon lui, à moins que l'on n'appelle reserve(), segmented_stack sera plus rapide.

Scott Wardle demande si la situation se corrigerait on produisait un segmented_vector et si on l'utilisait comme substrat à std::stack, le problème serait réglé. Matthew Bentley n'est pas convaincu; il parle de facteur de croissance lors d'allocations successives.

Michael Wong demande s'il présentera sa proposition à Issaquah. Matthew Bentley dit que le vol à partir de la Nouvelle-Zélande est une aventure.

Dietmar Kühl estime que le problème n'est pas std::stack mais bien le choix du substrat. Il y a un dialogue de sourd qui s'installe. Patrice Roy suggère que Scott Wardle avait une idée intéressante avec segmented_vector qui pourrait servir à d'autres égards, sans nuire au concept mis de l'avant pas Matthew Bentley. Il va y penser.

colony – Matthew Bentley

Matthew Bentley présente colony comme un conteneur non-ordonnancé qui permet les insertions et les suppressions très rapidement. Il dit que pour les cas d'utilisation visés, ce conteneur épargne de la mémoire et est très rapide. Il semble y avoir une variante de Skip List sous la couverture.

Staffan Tjernstrom se demande s'il y a beaucoup d'allocations. Matthew Bentley pense que c'est un malentendu.

Richard Smith pose des questions sur la complexité algorithmique des opérations de ce conteneur. Matthew Bentley donne des détails.

Patrice Roy demande si on présente colony à Issaquah. C'est un « oui » mou.

coroutines – Gor Nishanov

Gor Nishanov présente les coroutines « disparaissantes » en cinq minutes. Il met l'accent sur les éléments clés pour un jeu. Brillant bonhomme.

Jackie Kay demande si Tail Call Optimization devient effectivement nécessaire. Gor Nishanov dit qu'on peut les simuler par un enchaînement de continuations

On termine vers 18 h 20. Grosse journée. Je suis allé me prendre une salade à l'épicerie (avec un peu de crabe et de citron), une bière locale, un peu de poivre et une fourchette. On m'a demandé mes pièces d'identité à la caisse, première fois en trois voyages ici (oui, oui, on m'a carté, à 44 ans les cheveux gris et des enfants d'âge majeur!). À l'hôtel, tristement, j'ai constaté que mon sachet de poivre était vide et que la caissière n'avait pas mis ma fourchette dans mon sac. J'ai été gâté : l'hôtel a livré une fourchette à ma chambre.

J'ai brièvement parlé à Za et à son amie Cindy, qui fabriquaient des jujubes maison, retourné quelques courriels en suite aux travaux de la journée, et je suis revenu au colloque pour les Lightning Talks (je me sens mal d'avoir manqué ceux d'hier soir)

Lightning Talks

Ce sont de très courtes présentations en rafale. Rob Irving et Jason Turner offrent de faire de courtes entrevues avec les présentateurs par la suite. La salle est pas mal pleine (les deux tiers, je dirais), et il y a deux autres événements en même temps, dont un panel sur les gaffes de sécurité.

Vidéo : https://www.youtube.com/watch?v=tSq7yDwS1vM

Algorithm mnemonics – Tommy Bennett

Tommy Bennett (un ancien de Borland!) parle de « tatouages de cerveau » en relatant les instructions assembleur d'autres époques. Il présente quelques diapos amusantes et commence à programmer « live » mais il semble perdre la mémoire, ou se chamailler avec son clavier.

Il présente les algorithmes comme le STL Instruction Set. On rit un peu. Il fait l'apologie de vim et est extrêmement drôle.

Vidéo : https://www.youtube.com/watch?v=Nk3A0SiqJ8k

Using C++ 14 to mock C functions – Atila Neves

Atila Neves explique pourquoi faire un truc pareil. Il utilise une macro pour remplacer localement une fonction par une autre dans un bloc (bonne idée!).

Vidéo : https://www.youtube.com/watch?v=gjQG3RNfFxM

CodeCompass – Daniel Krupp

C'est un outil de visualisation graphique du code.

Vidéo : https://www.youtube.com/watch?v=1q79ij0uEZ0

Improving Windows Debuggers from the Inside Out – Ken Sykes

Ken Sykes raconte les améliorations les plus récentes apportées au débogueur de Windows. Ils avaient ouvert la porte aux extensions, mais il y en a eu des tonnes et c'était la confusion. En particulier, il parle de NatVis.

Ken Sykes parle aussi du Data Model du débogueur.

Vidéo : https://www.youtube.com/watch?v=rXVg07rtSiI

MessagePack(msgpack): A Compact and Fast Serialization Library – Takatoshi Kondo

Takatoshi Kondo se présente comme un contributeur aux bibliothèques Boost de messagerie. La bibliothèque dont il parle ressemble à du JSON.

Vidéo : https://www.youtube.com/watch?v=oJtSYKZWzx0

Orbits – Sandeep Gupta

Il montre un truc pour détecter les cycles dans un graphe. C'est une présentation amusante.

Vidéo : https://www.youtube.com/watch?v=8jbt-5Qub9E

A Static Alternative to Virtual Functions – Ben Deane

Ben Deane donne un truc pour remplacer les méthodes virtuelles par quelque chose de statique, en composant des fonctions dans un cadre générique. Le code est sur https://github.com/elbeno/autocomplete

Vidéo : https://www.youtube.com/watch?v=-o-Wjy_ISvs

Presenting Code – Jens Weller

Jens Weller propose sa perspective sur cette tâche, tenant compte du fait qu'une importante partie de l'audience verra chaque présentation ultérieurement sur un écran. Les diapos de cette présentation sont disponibles sur https://github.com/CppCon/CppCon2016/blob/master/Lightning Talks and Lunch Sessions/Presenting Code/Presenting Code - Jens Weller - CppCon 2016.pdf

Vidéo : https://www.youtube.com/watch?v=N1cWgqmWSio

An example of applying variadic templates to C-style code – Masako Toda

Un exemple d'accès à une BD. La présentatrice, Masako Toda, travaille chez Blizzard. C'est un tout petit exemple, mais charmant, qui fait fondre un programme complexe à deux lignes de code.

Vidéo : https://www.youtube.com/watch?v=vGUm3bQStVM

Qt Creator – Giuseppe D'Angelo

Giuseppe D'Angelo nous parle de Qt Creator, et le fait avec beaucoup d'enthousiasme.

Vidéo : https://www.youtube.com/watch?v=wvtFGa6XJDU

unsigned: A Guideline for Better Code– Jon Kalb

Jon Kalb fait un plaidoyer pour restreindre le recours aux entiers non-signés. Il parle de sa guerre en ligne avec James McNellis. Il soulève la question des conseils à donner aux programmeuses et aux programmeurs, et il est amusant.

Jon Kalb recommande d'utiliser unsigned pour des masques et des opérations bit à bit.

C'était amusant. Jon Kalb est un excellent showman.

On ferme à 21 h 52. Une grosse journée qui se complète, dans une semaine costaude. J'échange brièvement avec Jesse Williamson, qui a construit un système de attempt(f,args...) pour transformer les levées d'exceptions en forme monadique (des std::optional<R>, en fait). Un truc charmant. Il voulait mon avis, et se demandait comment gérer le cas des fonctions où R est void, alors je lui ai donné une piste. Il semblait content.

De retour à l'hôtel, plusieurs courriels de suivi des travaux de la journée ont déjà circulé (chic!). J'ai fignolé les diapos de ma présentation d'hier matin, rendu disponible le code de test et les chiffres que j'ai obtenus, puis je suis allé faire dodo.

Jour 3 22 septembre 2016

Ça commence à être dur sur le corps. Il ne me reste qu'un seul dodo ici (ce soir), car demain je risque de faie la sieste dans l'avion entre Vancouver et Montréal.

C'est fou le nombre de courriels techniques qui peuvent entrer dans le 3-4 heures de sommeil que j'ai pu prendre.

En ouvrant mon ordinateur, Google me rappelle qu'aujourd'hui, c'est l'automne  Du côté moins chouette, Za m'écrit qu'elle et les enfants combattent un vilain virus et sont à la clinique. On se sent loin dans ces moments...

Diapos : https://github.com/CppCon/CppCon2016/blob/master/Presentations/The MAME Story - From C to Modern C++/The MAME Story - From C to Modern C++ - Miodrag Milanovic - CppCon 2016.pdf

Vidéo : https://www.youtube.com/watch?v=wAUnUWYaA5s&list=PLHTh1InhhwT7J5jl4vAhO1WvGHUUFgUQH&index=13

Présentation de Miodrag Milanović

Je salue Miodrag Milanović de la part de mon ami David Viens, qui aurait bien aimé être dans la salle avec nous ce matin. Nous sommes plutôt nombreux ce matin, malgré la compétition très forte.

The MAME (Multi-Arcade Machine Emulator) story: From C to Modern C++

Miodrag Milanović présente le projet MAME en soi, les gens qui y contribuent, et et le fonctionnement du groupe qui travaille sur ce projet depuis qu'il en a pris la charge. Il avoue ne pas être un habitué des colloques, du moins en tant qu'orateur, mais il s'en sort bien et dégage beaucoup de douceur. Le projet MAME remonte à 1997 et a été mis sur pied par Nicola Salmoria; c'était écrit en C à l'origine.

Miodrag Milanović explique que l'un des objectifs de MAME est de placer la précision devant la « performance ». L'objectif est l'authenticité. C'est très intéressant. Miodrag Milanović en profite pour parler de divers mythes sur MAME (ce n'est pas une arcade, un émulateur universel, un jeu, ce n'est même pas techniquement une plateforme de jeu, malgré son nom!). C'est une entreprise de préservation du passé, pour éviter que ces idées ne soient oubliées ou perdues.

Miodrag Milanović exprime qu'il souhaite que MAME permette d'en apprendre sur le passé. Que le projet mène à la préservation du matériel et du logiciel. Qu'il permette un peu à l'enfance de persister.

Selon Miodrag Milanović, MAME n'émule pas de matériel récent sans l'accord des auteurs, et ne supporte l'émulation de logiciels que si au moins trois ans sont passés depuis la fin de la production.

Miodrag Milanović explique par un schéma que ce qu'ils font est transformer de vieux processeurs en code C++. Il relate le côté « sale » de la chose car il faut parfois manipuler du matériel contenant des substances empoisonnées. Il y a un volet exploratoire dans du code non-documenté au coeur de cette démarche. Les sources C++ occupent 151 Mo.

Miodrag Milanović fait un tour d'horizon des outils auxquels ils ont recours. Ils sont bien équipés, en compilateurs, outils d'analyse statique et autres.

Miodrag Milanović présente quelques saisies d'écran de leurs outils de développement, d'analyse et de débogage. Ils écrivent énormément de documentation et de commentaires, mais je pense qu'on peut les comprendre.

Miodrag Milanović traite ensuite de la modernisation du projet, qui était encore en C au début de l'année 2009. Aaron Giles a débuté la migration vers C++, et le code est en processus de modernisation. Ils ont fait ce mouvement pour que le code soit plus facile à comprendre et à entretenir. Les abus de variables globales rendaient très difficile la réutilisation de sections isolées du code. Ils visent une approche selon laquelle le code devient sa propre documentation. Ils ont commencé par compiler le code C avec un compilateur C++, plus strict, et en traitant les avertissements comme des erreurs. Ensuite, ils ont commencé à appliquer des techniques de programmation OO pour que le code soit plus facile à comprendre.

Miodrag Milanović relate que les plus gros irritants étaient les variables globales et les macros (il en reste encore). Il a fallu tenir à jour une trace rigoureuse des changements, et identifier clairement le code déprécié. Les expressions régulières les ont beaucoup aidé, puis clang-tidy a fait une différence dans leur productivité. Les templates variadiques ont contribué fortement à la réduction du code Boilerplate. Le gros morceaux pour éliminer les macros a été constexpr, qui fait des miracles.

Miodrag Milanović dit ensuite que les outils de synchronisation portables (mutex, thread, atomic, etc.) ont permis d'évacuer beaucoup de code assembleur. Ils souhaitent utiliser des coroutines, des modules (trop lents pour le moment) et la GSL.

Miodrag Milanović dit que leurs plans futurs incluent une version « console », et l'interaction avec l'IoT, une version Android, une version iOS... Il montre ensuite le genre de code qu'ils écrivent, qui se rapproche le plus possible de la documentation descriptive de la machine d'origine. Ils utilisent beaucoup de délégués (version maison, écrite à l'origine pour C++ 98) car les Callbacks sont fréquemment utilisés dans leur moteur.

Miodrag Milanović montre les (nombreuses!) plateformes supportées. Il fait ensuite un plaidoyer pour le code ouvert et les Releases réguliers (ils en font un le dernier mercredi de chaque mois). Bonne idée : il parle de ce que MAME aimerait offrir à C++ en retour.

Miodrag Milanović a la gentillesse de nous faire une démo... d'un vieux PC de 1997, avec affichage comme sur un CRT. Très cool! Quelques autres démos, dont pong comme Jason Turner hier.

Ce fut très agréable comme début de journée, plus même que je ne l'aurais pensé. Miodrag Milanović est un individu très agréable et ce qu'il avait préparé était intéressant à plusieurs égards.

Diapos :

Vidéo : https://www.youtube.com/watch?v=w4jq4frE5v4

Keynote de David Schwartz

Une dame dont le nom m'échappe (Hanieh Bastani?) prend le plancher et nous donne les informations d'usage. Demain matin, une séance de Jon Kalb s'est ajoutée àh sur les enum bitfields. Les prix pour les posters sont donnés.

David Schwartz est présenté par Howard Hinnant, rien de moins.

Developing Blockhain Software

David Schwartz se présente et explique ce que fait son employeur, puis passe aux blockchains.

Un blockchain enregistre des états et de l'historique (David Schwartz va très vite alors je ne pourrai pas prendre beaucoup de notes). En gros, l'idée des blockchains est de décentraliser l'effort de certification d'une transaction (typiquement monétaire). Évidemment, on parle de Bitcoin, le premier système de blockchain. Il explique pourquoi on transige en Bitcoins plutôt qu'avec des pommes par exemple (la durabilité joue un rôle).

Entre autre choses, Bitcoin règle le problème de double dépense (tu fais deux chèques à deux personnes, mais tu n'as les fonds que pour un seul des deux). Bitcoin est aussi à la fois une monnaie et un système de paiement.

La quantité de Bitcoins disponibles repose sur une forme de consensus social. C'est fixé à 21'000'000 Bitcoins pour le moment.

Chaque transaction contient son historique sous forme de métadonnées.

Plusieurs aspects du système reposent sur des mécanismes d'atteinte de consensus. L'ordonnancement des transactions est, évidemment, important.

David Schwartz discute de diverses architectures pour mettre en place un système globalisé de paiements. Il discute de crédit social, d'emprunt, d'échanges d'autres types de ressources. C'est archi plein de contenu, drôle et ça va très vite. En fait, le système permet à tous les participants d'avoir des fonds négatifs à l'occasion et de participer à des systèmes d'emprunt.

David Schwartz mentionne les blockchains privés et leur utilité, entre autres pour réduire les risques d'attaque (il parle de frenemies pour à la fois amis et ennemis). Sa présentation montre, en plus d'énormément de contenu architectural, à quel point la confiance et le consensus social importent dans tout ce qui a trait aux transactions monétaires.

David Schwartz trace une distinction entre les paiements de petite et de grande valeur; sur le plan systémique, ils n'ont pas les mêmes conséquences du tout. C'est une perspective de très haut niveau que la sienne. Il trace des liens avec le (classique) problème des généraux byzantins. Il suit avec le protocole PBFT, qui utilise la technique d'entente des généraux byzantins et a une certains tolérance aux pannes. Ce protocole semble bien se combiner avec des techniques de chiffrement de données. David Schwartz montre au passage que plusieurs problèmes du monde des blockchains sont des problèmes de généraux byzantins.

David Schwartz entre dans le code après 40 minutes investies pour « nous transformer en experts » de blockchain 

David Schwartz nous indique que les blockchains sont publiques; elle doivent être des forteresses à toutes fins pratiques. Il relate un bogue de corruption vécu il y a quelques mois, et explique qu'il a fallu faire en sorte de créer un consensus pour le régler, chose particulièrement difficile. Une partie du traitement des blockchains est parallélisable, une autre partie ne l'est pas du tout.

Pour des raisons évidentes (temps de calcul!), l'essentiel du code de traitement de blockchains est fait en C++. Le mouvement sert beaucoup, les λ aussi, de même que les coroutines, le polymorphisme statique, des outils scomme optional<T> et shared_ptr<T>, l'encapsulation au sens d'isolation du code.

David Schwartz dit faire beaucoup d'optimisations manuelles et dépendre beaucoup du inlining. Il dit ne pas aimer le Slicing mais semble au courant du clonage. Il combine des pointeurs « forts » et des weak_ptr dans sa Cache. Il utilise NuDB qui est un dépôt de paires clé/valeur. Il explique le raisonnement technique derrière ce choix. NuDB est header-only, repose sur un visiteur générique et sur static_assert. Il utilise Beast, qui ressemble à Boost pour les accès http. Il utilise une version maison des concepts.

Il termine sa présentation archi-accélérée vers 11 h 35

Q : tu as parlé d'attaques de pire cas, mais as-tu des attaques de meilleur cas aussi?

David Schwartz : oui, mais ça devrait être plus facile à résoudre, et il faut payer un petit peu pour transiger. Faut par contre être prudents avec les machines de force différente.

Jens Weller : et les ordinateurs quantiques?

David Schwartz : je suis le dossier de près. Je pense qu'on a encore environ huit ans de calme devant nous, mais je peux me tromper. Et c'est difficile de prendre des actions préventives car on ne sait pas exactement ce dont ils auront l'air.

Gor Nishanov : quelles techniques de hashage utilisez-vous?

David Schwartz : on utilise des techniques qui reposent sur la participation de beaucoup d'autres noeuds. Il n'y a pas de solution parfaite. J'ai des projets de doctorat à offrir s'il y a des intéressé(e)s. On ne sais pas ni où est la zone dangereuse, ni ce qu'il faudra faire quand on s'en approchera. Il discute brièvement de la tolérance aux pannes du système (je te donne une preuve que je te dois des sous, je plante, je reviens, je te dois encore de l'argent)

Q : comparaison des compilateurs?

David Schwartz : la plupart des compilateurs majeurs livrent la marchandise. C'est utile d'en utiliser plusieurs pour dépister les bogues.

Bjarne Stroustrup : le Slicing est-il un combat à mener encore aujourd'hui?

David Schwartz : à mes yeux. le plus gros problème de C++ est le Slicing. Ça surprend les débutants.

Q : vous utilisez des générateurs de nombres pseudoaléaloires pour saler les hash, mais avec du code ouvert. Préoccupé?

David Schwartz : explique en détail comment son système fonctionne et pourquoi le hasard est bien généré. Il compare les « vrais » nombres aléatoires et les nombres pseudoaléatoires à l'eau en comparaison avec l'eau bénite, au sens où on n'a pas de test permettant de les départager; on se bidonne un peu.

On ferme vers 11 h 50. Beaucoup de contenu. À revoir en vidéo.

Truc sympathique : il y avait de la nourriture chaude à proximité. Pas donné (11 USD pour un bol de nouilles et un biscuit) mais étant donné que je me dirige vers un panel sur la compression de données où participe une dame avec entre autres Stephanie Hurlburt, personne avec laquelle j'échange des idées à l'occasion (en particulier sur l'intégration des femmes dans le marché du travail et leur accueil dans les milieux scientifiques; Stephanie Hurlburt donne dans la réalité virtuelle fait beaucoup d'efforts pour la féminisation de la force de travail), manger une bouchée ne fera pas de tort.

Présentation de Rich Geldreich et Stephanie Hurlburt

Petite jasette avec Gabriel Aubut-Lussier sur les travaux de SG14 la veille, puis la présentation commence vers 12 h 35.

Texture Compression

Stephanie Hurlburt et Rich Geldreich se présentent et expliquent pourquoi ils ont recours à C++ dans le cadre de leurs travaux. Ils commencent à profiter de C++ 11, en particulier les λ car ils cherchent à adresser le problème clé de la compression des textures dans le contexte des jeux vidéos. Des textures plus petites, c'est des téléchargements plus rapides et, selon eux, plus de ventes.

Stephanie Hurlburt parle parle des formats de textures utilisés dans les GPU, qui imposent des contraintes particulières et ont pour conséquence de réduire la qualité des efforts de compression.

Stephanie Hurlburt fait un tour rapide des diverses caractéristiques de formats de textures, et mentionne que certains effets peuvent être pertinents dans certains cas et mauvais dans d'autres cas (une Normal Map peut rendre une image plus jolie mais devenir nuisible lorsqu'appliquée sur certains objets)

Rich Geldreich poursuit sur les subtilités des diverses formes de textures. Stephanie Hurlburt parle de leurs options, incluant un format maison, qui servent à transcoder d'un format à l'autre pour profiter du GPU sans avoir à s'y adapter. Rich Geldreich rappelle que ce qui fait un bon format compressé pour l'exécution d'un jeu ne fait pas nécessairement un bon format compressés pour le téléchargement des données. Stephanie Hurlburt indique que les Jpeg compressent mieux que les formats propres aux GPU, mais montrent des artéfacts.

Stephanie Hurlburt dit que le transcodage est plus rapide que la compression, ce qui leur permet de réaliser leur tâche juste-à-temps. Rich Geldreich parle du point d'équilibre entre la vitesse de compression et la qualité. Stephanie Hurlburt dit que la qualité est plus un art qu'une science, et que le type d'artéfact joue autant (sinon plus) que la quantité d'artéfacts.

Ils relatent le progrès de leurs travaux courants, qui donnent un peu dans la recherche. Stephanie Hurlburt enchaîne sur les nuances entre compression lossless et compression lossy. Rich Geldreich parle de mesurer diverses techniques. Sa présentation des données sur diverses approches à la compression lossless est intéressante, et met en relief qu'on ne devrait pas essayer de réécrire les outils standards.

Fedor Pikus : peut-on paralléliser?

Rich Geldreich : certains formats sont très séquentiels.

Stephanie Hurlburt : le CPU n'a pas besoin de savoir quel format le GPU utilise.

Q : et la compression de maillages?

Rich Geldreich : je ne suis pas un spécialiste du domaine. J'ai tellement travaillé avec les textures... Normalement, on compresse la vidéo, puis les textures sont au deuxième rang.

Stephanie Hurlburt : dans la réalité virtuelle, ça peut aider.

Q : peut-on utiliser des textures dans les biosciences?

Rich Geldreich : encoder les régions d'intérêt est possible. On utilise des mipmaps, le décodage en parallèle est possible.

Stephanie Hurlburt : on adapte nos produits aux besoins spécifiques des gens.

Rich Geldreich : je pourrais offrir une API mais je ne vois pas qui en voudrait.

J'ai pris un peu de temps pour bavarder avec Gabriel Aubut-Lussier, qui est rendu chef de groupe dans son entreprise et qui vit des problèmes intéressants. J'ai aussi eu le plaisir e féliciter Stephanie Hurlburt en personne pour ses efforts.

Diapos : https://github.com/CppCon/CppCon2016/blob/master/Presentations/Constant Fun/Constant Fun - Dietmar Kuehl - CppCon 2016.pdf

Vidéo : https://www.youtube.com/watch?v=xWmdcvTedbc&list=PLHTh1InhhwT7J5jl4vAhO1WvGHUUFgUQH&index=26

Présentation de Dietmar Kühl

J'ai croisé Jackie Kay qui travaillait dehors, son laptop sur la rampe aux abords du vide; pas nerveuse... Je suis allé blaguer avec elle. On commence vers 14 h.

Constant Fun

Dietmar Kühl débute sa présentation avec des jeux de mots sur le mot fun et le mot Great. Il suggère qu'on présume qu'il a raison mais qu'on vérifie ses affirmations.

Sa présentation portera principalement sur constexpr. Il ira nous faire une map avec tri à la compilation.

Dietmar Kühl présente un résumé de ce qu'est une expression constante (incluant sizeof(x), les littéraux primitifs, les expressions qui ne dépendent que d'autres expressions constantes, etc.)

Pourquoi utiliser constexpr? Ça sauve du temps! Ça mémoïse les résultats, ça sort les calculs des boucles, et ça peut optimiser des branchements. Toutefois, les calculs sont faits une fois par unité de traduction. Les expressions constantes apparaissent dans plusieurs contexte, qu'il liste. Dietmar Kühl fait remarquer que const n'évalue pas toujours les expressions à la compilation, mais constexpr, si. Ça règle des ennuis d'ordre d'initialisation et des risques de conditions de course.

Les fonctions constexpr sont requises pour certaines abstractions, incluant les littéraux maison. Dietmar Kühl donne un exemple de bitmask vs constexpr, qui utilise des énumérations fortes.

Il y a bien sûr des contraintes : types littéraux seulement, pas de méthodes virtuelles, paramètres connus à la compilation, pas de goto (mais switch est permis, car c'est « sous contrôle »), de try, de variables static, d'assembleur inline, etc. Avec C++ 11, c'est plus strict encore. Note personnelle : vérifier si Duff's Device constexpr est possible. La contrainte sur les types littéraux tient entre autres au fait que les variables constexpr doivent avoir un destructeur trivial, n'étant jamais vraiment détruites. L'opérateur typeid peut être utilisé, mais pas sur un objet polymorphique.

Les noms sont constexpr en général, dans la mesure où ils réfèrent à des entités constexpr. Dans le contexte d'une fonction constexpr, le contexte peut donner des paramètres connus à la compilation ou pas. Un paramètre ne peut être constexpr, et on ne peut pas surcharger une fonction sur la base du contexte.

On se lance dans une map qui soit constexpr, et qui fait la correspondance entre des string (au sens large du terme, pas juste std::string) et des enum.

Dietmar Kühl utilisera string_view, qui est un type littéral constexpr, à titre de clé (le substrat sera un const char*)

Le constructeur de string_view qui prend un char const* initialise end à find(s,unreachable(), \'0'), c'est brillant

L'implémentation de unreachable (un foncteur générique) est triviale

Le find() de C++ 17 est constexpr et remplace la boucle par une récursive

Dietmar Kühl fait un littéral maison _sv pour string_view

Dietmar Kühl fait une fonction access qui fait un find_if constexpr à l'interne et lève une exception si on n'a pas trouvé. Les matchers utilisés sont constexpr.

Vittorio Romeo fait remarquer qu'on pourra utiliser une λ mais seulement à partir de C++ 17

Dietmar Kühl montre qu'on peut fait un switch(map_access(m,key)) avec des case map_access(m,"one"_sv): par exemple

Sa map est en fait un tableau de pair<string_view,int>

Pour faire une map à proprement dit, on ne pourrat pas utiliser une initializer_list car son size() n'est pas constexpr. Il suggère une make_map() variadique et constexpr

make_map(pair<F,S>...p)

Pour le tri, on peut faire un msort(array<T,N>) qui fait un tri fusion des deux moitiés. Il utilise if constexpr comme condition de terminaison, mais on peut le faire avec des enable_if (mais il injecte un paramètre bidon = void à une des deux signatures pour éviter que le compilateur ne se plaigne)

Pour choisir les éléments par indices, il fait une fonction select(array<T,N>,index_sequence<I...>) et mk_sequence et mk_indices (voir les diapos pour les détails)

Le merge() fait une fusion à la Lisp avec cons() et tail()

Le genre de code qui se fait avec C++ 11, mais qui est vraiment plus amusant avec C++ 14

... mais il se trouve que std::sort() peut être constexpr à un détail près, le support des tableaux de taille nulle. Il montre une solution qui repose sur un QuickSort vanille et un partition constexpr... et un constexpr swap()

Dietmar Kühl enchaîne avec une fabrique de maps

Dietmar Kühl fait un static_assert sur un appel à find() dans sa map(). Test unitaire!

Dietmar Kühl fait remarquer qu'il faut faire attention à constexpr. Cela transforme le comportement indéfini en erreurs.

Avec C++ 17, les λ sont constexpr. Il nous reste à rendre les algorithmes constexpr.

Vittorio Romeo demande pourquoi les algorithmes ne sont pas constexpr. Dietmar Kühl dit qu'on a reçu une proposition à Oulu mais que c'est arrivé un peu tard

: quelle est la raison de la grande différence entre sort() et merge_sort() dans les graphiques? Dietmar Kühl : l'une des deux est récursive, c'est plus lourd.

: doit-on tout rendre constexpr? Dietmar Kühl : mes expérimentations sont limitées et le risque est que le code est généré dans chaque unité de traduction et ça peut coûter cher en espace. Au moins, gardez les static_assert dans un .cpp

Vittorio Romeo parle de l'optimisation résultante du passage de code récursif à code basé tableaux.

Dietmar Kühl disserte un peu sur les différences des calculs constexpr et non-constexpr sur les nombres à virgule flottante

Quelques questions sont posées sur les fonctions mathématiques et constexpr. Dietmar Kühl dit que cellles qui ont des effets de bord sont exclues.

Pause à 15 h 3. Quelques personnes à saluer au passage, on blague un peu. Quelqu'un qui était dans ma classe me dit, à la lueur de la présentation de Dietmar Kühl, que cette année semble être celle des abstractions à coût nul. Un autre vient me voir en souriant pour me dire qu'il a aimé mon cours (c'est gentil!).

Diapos :

Vidéo : https://www.youtube.com/watch?v=uQSQy-7lveQ

Présentation de Ryan Quinn

Salle pleine à peu près à , mais sujet un peu pointu. On parle d'hyperviseurs.

Making C++ and the STL Work in the Linux / Windows Kernels

Ryan Quinn explique que les hyperviseurs commerciaux sont déplaisants dans un contexte de recherche, du fait qu'ils supportent beaucoup de fonctionnalités héritées (legacy). Son objectif était d'exécuter un très petit programme dans le noyau d'un système d'exploitation. C'est interdit dans Linux, par décret de Linus Torvalds.

Ryan Quinn passe par un chargeur de format ELF pour charger un programme C++. Le format ELF est découpé en sections, chacune comportant une partie des ressources requises pour exécuter le programme. Les sections sont organisées en segments qu déterminent les endroits où l'éditeur de liens placera le code en pratique.

Ensuite, Ryan Quinn crée un pilote « squelette », place le code du programme au bon endroit et regarde si le résultat est conforme aux attentes. Ensuite, « le fun commence »

Ryan Quinn a conçu une classe simplifiée. L'héritage a bien fonctionné, les λ aussi. Les ennuis commencent avec les globales, en particulier leurs constructeurs et leurs destructeurs. Il a donc fallu ajouter une bibliothèque offrant local_init() et local_fini(), pour exécuter ces deux phases dans la vie des programmes. En C++, ces fonctions ne sont pas optionnelles, et il faut les exécuter. Ryan Quinn mentionne la Red Zone, mentionnée en 2001 par Eli Bendersky, qu'il faut éviter pour ne pas avoir de corruption de mémoire.

Pour ce qui est de la bibliothèque standard, faut savoir laquelle. Ryan Quinn a joué avec libc++ et libc++abi, qui fonctionnent bien mais utilisent beaucoup de pile alors que Linux, par défaut, utilise 8 Ko de pile dans le noyau. Aussi, unordered_map et sa fonction de hashage exige des opérations à virgule flottante, non-supportées dans le noyau.

Ryan Quinn a dû apprendre comment compiler le tout. Il y a une option -nostdlib mais il semble qu'elle soit ignorée.

Ryan Quinn enchaîne avec dynamic_cast. Il a fait le constat que c'est un truc de la bibliothèque standard, pas un truc du langage. Il a ensuite fait la découverte de la gestion des symboles définis plusieurs fois, ou marqués « weak ». Un apprentissage de l'ABI du processeur Itanium.

Ensuite, Ryan Quinn a confronté la question des exceptions, et a exploré le Stack Unwinding. Trois bibliothèques existaient (gcc, Google, Apple), toutes écrites pour le User Space. Ils ont pris DWARF4 qui entrepose l'information d'Unwinding en formt compressé. Ça génère pas mal de code.

Reste que Ryan Quinn a réussi et a un hyperviseur qui fonctionne!

Q : et sur Windows?

Ryan Quinn : la couche qu'on utilise fonctionne bien.

: comment t'en sors-tu avec 8 Ko de pile dans un langage comme C++?

Ryan Quinn : je fais ma propre pile!

Jeff Trull : au début, t'as préféré charger un ELF manuellement plutôt que compiler un noyau...

Ryan Quinn : c'était un peu de l'inexpérience, et un peu que je ne savais pas si ça donnerait une solution portable.

: comment la communauté Linux a-t-elle réagi?

Ryan Quinn : je me cache 

: j'aimerais mettre une de mes applications dans le noyau. Avec ton site, en ai-je assez pour y arriver?

Ryan Quinn : pas si mal (il montre comment).

Ryan Quinn trace un lien entre ses efforts et les uninoyaux.

Ce que Ryan Quinn a fait est courageux, aller de front à l'encontre des mythes d'une communauté quelque peu agressive. Et c'est très cool!

Je mange une bouchée en bavardant avec Lisa Lippincott et je me dirige vers la dernière présentation de la journée pour moi, du fait que ce soir j'ai une rencontre de planification pour CppCon 2017.

Diapos : https://github.com/CppCon/CppCon2016/blob/master/Presentations/Variadic expansion in examples/Variadic expansion in examples - Micha%C5%82 Dominiak - CppCon 2016.pdf

Vidéo : https://www.youtube.com/watch?v=Os5YLB5D2BU

Présentation de Michał Dominiak

Cette présentation a lieu dans l'immense Bowie Hall, qui n'est évidemment pas plein car nous ne sommes pas en plénière. Le sujet doit en attirer plusieurs.

J'apprends par courriel que le dernier Marillion est arrivé. J'ai mon lien pour le téléchargement, ayant acheté l'album en mode « socio-financement » l'an dernier. Une belle gâterie!

Variadic Expansion in Examples

Michał Dominiak présente les approches traditionnelles reposant sur des macros, et montre par des exemples les difficultés de débogage qui découlent d'une telle pratique. Ceci justifie le passage aux templates variadiques. Je compte noter quelques trucs sympathiques quand ils passeront, étant donné que c'est un sujet que j'aime bien mais avec lequel je suis plutôt à l'aise.

En pratique, il y a beaucoup de code sur les diapos, rien qui me heurte particulièrement, mais rien que je ne prendrais en note pour le moment. Il y a des prestations qui sont plus à propos pour le petit écran, ce qui n'enlève rien à la qualité du contenu.

Bon, direction souper du comité.

Souper du comité de planification

Nous sommes allés dans un restaurant qui se disait une pizzeria californienne, mais la serveuse recommandait le jambalaya plutôt que la pizza et j'ai pris une salade thaï avec une bière locale, une rousse qui porte le nom de Mayonnaise mais qui est en pratique plutôt fruitée. Bavardage avec les toujours sympathiques Billy Baker, Jesse Williamson et Mitch Carlson.

Au retour pour la rencontre de planification, il y a de la confusion sur le local de la rencontre car notre logiciel de gestion des salles fait des siennes. On finit par convenir d'un lieu et on s'installe.

Rencontre du comité de planification

On doit être entre 30 et 35 personnes dans la salle, à l'oeil. Il y a des événements ailleurs dans le bâtiment, et notre rencontre est plus un truc organisationnel qu'un truc conceptuel ou technique. Après un peu de confusion, on débute vers 20 h 35.

Bryce Adelstein-Lelbach assure l'accueil. Jon Kalb se dit confiant que l'on frappe le cap du 1000 participant(e)s en 2017.

Remarques :

On passe ensuite à un autre dossier, à mon sens plus profond et plus important.

On ferme vers 22 h 11. Chandler Carruth vient me serrer la main; je pense qu'il est content que leur (excellente!) proposition ait été bien reçue.

Je reviens à l'hôtel en bavardant avec Gabriel Aubut-Lussier, qui va rejoindre des amis non-loin. Dodo bientôt. Dernier dodo avant de revenir vers ma belle et mes chiboukis.

Jour 4 23 septembre 2016

Je suis parti de l'hôtel versh 5. Mes bagages sont restés derrière moi, et je les cueillerai cet après-midi en allant vers l'aéroport. J'ai hâte de revoir ma famille et mon amoureuse!

Arrivé sur les lieux du colloque. Sergey Zubkov travaille sur un truc et on échange quelques mots (j'aurais voulu assister à sa présentation, mais j'étais pris ailleurs). Miodrag Milanović vient s'installer non-loin, fatigué mais content de sa semaine, et j'en profite pour le féliciter de son excellente prestation. Je passe aussi remercier les gens qui ont travaillé en soutien à la logistique de l'événement (organisation des salles, café, nourriture, etc.) car, à mon humble avis, le travail a été bien fait.

J'essaie de ficeler ce qui reste à ficeler ce matin, en particulier m'assurer que les participant(e)s à mon cours de la fin de semaine dernière aient les documents promis (il me reste des retouches à faire) et que je puisse leur envoyer un petit mot de remerciement. C'est pas simple car beaucoup de gens ont de la jasette (on peut comprendre; c'est le dernier matin après tout).

Jon Kalb a ajouté une présentation de son cru sur une technique que je connais versh (les présentations de cet événement débutent pour la plupart versh, mais il y a des exceptions), mais je vais y aller quand même. De un, c'est un (très) bon présentateur, et de deux, c'est une forme de remerciement pour son bon travail.

Présentation de Jon Kalb

Je m'installe dans la salle vers 7 h 55 et Jon Kalb fait remarquer à la blague que je suis un autre représentant de la côte Est. Il a l'impression que tous les gens debout à cette heure sont en décalage horaire.

Using enum struct as Bitfields

Jon Kalb présente le sujet en indiquant qu'il a « volé » l'idée à Anthony Williams (qui est dans la salle, d'ailleurs). Il présente les enum struct (énumérations fortes; on peut aussi écrire enum class et avoir le même effet) et leurs vertus, et vise à expliquer comment on peut les utiliser pour représenter efficacement des bitfields.

Je n'ai pas pris de notes, mais c'était bien fait. Sa présentation peut être vue dans Internet.

Chaque matin, nous recevons un court sondage en ligne portant sur notre appréciation de la journée précédente; ce matin, pour une raison que j'ignore, les événements sur lesquels nous sommes sondés sont ceux de 2015. J'informe Jon Kalb au passage de cet imbroglio, puis je me déplace vers la prochaine présentation. Petit salut au passage (peut-être le dernier de la semaine) à Walter E. Brown, charmant monsieur s'il en est un.#

Diapos :

Vidéo : https://www.youtube.com/watch?v=uhgrD_B1RhQ&index=39&list=PLHTh1InhhwT7J5jl4vAhO1WvGHUUFgUQH

Présentation de Paul E. McKenney, Maged M. Michael et Michael Wong

Salle à peu près pleine au tiers, mais c'est un contenu extrêmement spécialisé.

A lock-free concurrency toolkit for deferred reclamation and optimistic speculation

Michael Wong prend la parole Ils nous présenteront une boîte à outils pour la concurrence, qu'ils comptent proposer pour C++ 20. Cette boîte à outils comprend RCU et les Hazard Pointers.

Michael Wong suggère d'être paresseux et de structurer la remise à plus tard de l'abandon des objets désuets.

Michael Wong dit que ce qui est proposé ce matin s'adjoint à atomic_shared_ptr

Michael Wong présente un exemple avec beaucoup de requêtes de lecture (le Zoo de Schrödinger, CACM 2013). Heureusement, les délais entre les requêtes permettent d'insérer de la synchronisation. Le truc est de refuser que les insertions et les suppressions soient pleinement ordonnancées.

Michael Wong dit que pour fins d'efficacité, on peut échanger la certitude contre la « performance » et l'échelonnabilité.

Michael Wong rappelle que la vitesse de la lumière est finie et qu'on est coincés par cette barrière. Il enchaîne avec des considérations d'opérations atomiques sur des shared_ptr.

Michael Wong présente diverses options sous forme tabulaire. Diapos pour ceci. C'est important.

Maged M. Michael prend le relais. Il présente un Wide CAS qui montre un accès mémoire dangereux, un ABA et une réclamation impropre de mémoire. Il a un joli ABA qui entre sur une diapo. Il a aussi une jolie faute de réclamation qui entre sur une diapo. Je vais les lui emprunter pour mon cours de parallélisme.

Maged M. Michael explique qu'un Hazard Pointer est single-writer, single-owner, many readers. On a quelques exemples sur les diapos mais je n'ai pas le temps de les prendre. À considérer pour mes cours de parallélisme l'an prochain.

Il y a un concept de « domaine » pour les Hazard Pointers. Maged M. Michael présente les enjeux de design, et ils sont nombreux. C'est une présentation costaude.

Paul E. McKenney suit. Il trace les contours de RCU, mais c'est un résumé condensé de ce que j'ai vu avec lui plus tôt cette semaine. Pour moi, la clé ce matin était la perspective de haut niveau proposée par Michael Wong.

Je parle avec quelques amis d'Ubisoft Montréal qui me disent avoir aimé leur semaine, mais avoir trop souvent assisté à une présentation où la conférencière ou le conférencier oubliait de donner d'office la direction de sa présentation, ce qui compliquait la compréhension et le suivi dans l'audience.

Je suis arrivé trop tard pour le yogourt, mais il restait des oranges.

Diapos : https://github.com/CppCon/CppCon2016/blob/master/Presentations/Lifetime Safety By Default - Making Code Leak-Free by Construction/Lifetime Safety By Default - Making Code Leak-Free by Construction - Herb Sutter - CppCon 2016.pdf

Vidéo : https://www.youtube.com/watch?v=JfmTagWcqoE

Keynote de Herb Sutter

Bryce Adelstein Lelbach prend le plancher pour nous dire que l'erreur sur le sondage de ce matin a été corrigée et que le sondage du jour est un peu plus long que les autres, question de faire un retour sur la semaine.

Il y a un tirage pour une XBox et c'est Fedor Pikus qui l'a remportée.

Herb Sutter prend le plancher.

Lifetime Safety... By Default: Making Code Leak-Free by Construction

Herb Sutter remercie les gens d'être présents.

Herb Sutter veut parler des propriétaires des ressources. L'objectif est de détruire un objet dès qu'il n'est plus nécessaire.

Les trois cas clés sont :

Herb Sutter parle ensuite des relations clés de la programmation orientée objet, qui nous donnent une gestion de ressources qui est correcte par construction :

Herb Sutter fait remarquer qu'on peut libérer un arbre itérativement et récursivement. L'approche récursive et la pile tendent à se nuire mutuellement.

Herb Sutter discute du choix entre pile (récursif) et temps (itératif), et suggère d'explorer le tas avec des libérations à délais (deferred).

Herb Sutter aborde ensuite la question des listes doublement chaînées. Il présente la liste doublement chaînée comme étant un arbre de largeur . Cela garantit qu'une récursion sera de complexité sur la pile, soit le pire cas.

Herb Sutter fait remarquer que si on arbre donne accès à ses noeuds, l'abstraction la plus à propos est un shared_ptr avec son aliasing constructor.

Herb Sutter poursuit avec un graphe. Le shared_ptr est encore à sa place.

Herb Sutter demande quoi utiliser pour une fabrique. Il étend à une paire fabrique + Cache. Ça le fait passer à une combinaison shared_ptr et weak_ptr. Le code est sur isocpp.org.

Herb Sutter passe à des techniques pour éviter des cycles entre les modules, chose qui arrive quand on est imprudents pour laquelle shared_ptr ne nous aide pas. C'est typiquement un truc qui naît d'une structure hétérogène, et c'est souvent accidentel. Un truc pour l'éviter est de ne pas passer un pointeur propriétaire à un noeud d'origine inconnue. Évidemment, on fait parfois des Callbacks, alors...

Herb Sutter mentionne deux types de cycles, soit un qui soit « compositionnel » et hétérogène. En gros, faut éviter ça. L'autre est un cycle intra-module (local), comme dans un graphe ou une liste circulaire. La structure est correcte par construction, comme toujours, mais le nettoyage n'est pas simple. Pour un graphe, la représentation se fait bien avec un vecteur, en rendant le conteneur responsable de la vie des noeuds. Ça peut être lourd de nettoyer les noeuds au moment opportun par contre.

Herb Sutter dit qu'une dizaine de personnes ont donné de bonnes réponses à son puzzle. Il donne des « Microsoft iPad » à trois d'entre eux et on se bidonne fort. Un a utilisé une pile explicite, un autre un appel à un algorithme de la STL, et un troisième qui a utilisé une λ et s'est amusé avec les noms (un mark-sweep)

: une question sur COM et les pointeurs intrusifs sont unt terrible idée

Herb Sutter : non, c'est une bonne idée, mais pas en exposant des pointeurs bruts.

Q : les weak_ptr et make_shared() peuvent coûter cher lorsque pris ensemble

Herb Sutter : on s'en reparle, la présentation n'est pas finie.

Herb Sutter : les pointeurs intelligents standards ont leurs limites. Il passe ensuite dans son deferred_heap, proposé cette semaine sur son blogue. Je n'ai pas pris de notes parce que je fignolais des trucs pour mes étudiant(e)s de la fin de semaine dernière, mais c'est très bien expliqué sur le blogue en question. Herb Sutter mentionne que Hans Boehm lui a expliqué que cette technique est celle utilisée par Android pour nettoyer les objets Java.

Eric Niebler suggère un exercice pour détruire un arbre binaire sans récursivité, sans passer par le tas, et en espace constant.

On fait des blagues sur le concept de collecte d'ordures (un concept Voldemort ici). Herb Sutter parle un peu de ses décisions de design.

C'était très bien. J'ai profité des derniers moments pour finaliser les documents de ma classe. J'espère que les participant(e)s apprécieront!

CppCon 2017 Planning Committee Work Session

Nous sommes un bon groupe, environ 25-30 personnes. On discute brièvement du code de conduite, mais ça ne semble pas rencontrer quelque blocage que ce soit.

Jon Kalb informe les gens que c'est une séance de travail.

Jon Kalb : le problème le plus immédiat est l'enregistrement / l'accueil. Il y a des gens qui ont des badges où on voit « See Jon » et plusieurs ne sont pas venus me voir... donc j'ai trop de chocolat. Lloyd Moore dit respecter l'ordre de priorités de Jon Kalb. On a le choix entre chocolat au lait et chocolat noir; je prends au lait parce que quelque chose me dit que mon amoureuse va les préférer (t'en fais pas Za, ils sont tout petits).

Jon Kalb parle ensuite de Rachel qui en a trop fait et aimerait en faire moins. Elle fait typiquement du recrutement, mais elle s'est aussi chargée des visites des lieux. Une de mes étudiant(e)s les plus enthousiastes, Margret Steele, s'offre pour organiser cela. Jon Kalb dit qu'on a perdu de l'argent avec ça cette année mais qu'il n'est pas contre. Mitch Carlson fait remarquer que les visites ont chevauché les classes et que certain(e)s étudiant(e)s pensaient pouvoir faire les deux, donc ont perdu leur dépôt.

Jon Kalb dit qu'on avait des parapluies-souvenirs pour les visiteuses et les visiteurs, car il pleut souvent à Seattle, mais cette année ils n'ont pas été distribués (faute de pluie). Margret Steele propose un plan de match.

Jon Kalb se dit heureux du fait que l'accueil s'est mieux passé que lors des années précédentes. Tout était en place. Ce qui était complexe était la jonction entre l'accueil et la visite. Brett Searles dit que Kate Gregory avait suggéré le musée de l'informatique. Jon Kalb indique que nous avons vendu tous les billets pour cette visite, et ce parce que nous étions prêts (nous savions combien de places nous avions, combien ça coûterait).

Bryce Adelstein Lelbach dit qu'il faut resserrer la démarche car il ne nous reste pas beaucoup de temps. Jon Kalb aborde la question des classes. Il dit que ça s'est bien passé cette année, et se demande si on devrait ouvrir la porte à des classes post-colloque aussi.

Jon Kalb parle du boulot de registraire, occupé par Marshall Clow pour le moment; ce dernier est pas mal occupé et il serait sain de pouvoir le remplacer. En particulier, les présentatrices et les présentateurs négligent de s'inscrire. Yuval Hager s'offre. Merci! Jon Kalb dit qu'il nous faudrait un compte partagé pour EventBrite, qui permet d'écrire aux gens; Bryce Adelstein Lelbach est contre car le compte serait partagé et qu'il y a de l'information personnelle et financière associée à cet outil.

Jon Kalb dit qu'il y a beaucoup de documents sur Google Drive. On a besoin d'une meilleure organisation de documents. On échange un peu sur l'organisation des tâches. Lloyd Moore suggère Trello pour le suivi des tâches. On veut trancher bientôt pour commencer le boulot rapidement. Bryce Adelstein Lelbach dit qu'on est peut-être au point où il faudrait payer une firme qui prend tout en charge pour nous libérer, car la firme viendrait avec son logiciel et serait imputable. On se questionne sur la possibilité de joindre CppCon et C++ Now, mais même si les organisateurs sont en partie les mêmes, il s'agit de deux entités légales disjointes.

On cesse les travaux vers 13 h 35 car le panel final de la semaine est à 14 h et Bryce Adelstein Lelbach doit y siéger.

En allant à la salle de bains, je prends la décision un peu folle de poursuivre la tradition entreprise au cours des années précédentes et de me procurer un livre (un libraire universitaire est sur les lieux avec nous chaque année, et prépare une sélection spéciale pour les fins de l'événement). C'est un « vieux » livre mais qui contient des informations difficiles à trouver ailleurs, le tout sur un un sujet qui a mauvaise réputation. Il m'accompagnera dans l'avion si jamais j'ai de la difficulté à dormir.

Vidéo : https://www.youtube.com/watch?v=j84pZM840eI

Panel – Implementing the Standard Library

Je m'installe pour profiter du panel, au moins 45-60 minutes (je vais devoir quitter ensuite pour prendre mes trucs à l'hôtel et me diriger vers l'aéroport).

Participants : Bryce Adelstein Lelbach, Walter E. Brown, Casey Carter, Marshall Clow, Eric Fiselier, Howard Hinnant, Stephan T. Lavavej, Alisdair Meredith, Anthony Williams et Michael Wong

Bryce Adelstein Lelbach est à l'animation. Il demande aux gens un truc qu'ils ont implémenté

Stephan T. Lavavej a implémenté INVOKE, et a retiré des trucs sataniques comme auto_ptr et random_shuffle

Howard Hinnant dit qu'il a implémenté des trucs pour ajouter et enlever des éléments de map et set en réduisant leur consommation de mémoire. Il a implémenté libc++ et la bibliothèque standard de Code Warrior

Casey Carter travaille sur Ranges TS et veut parler de std::optional, std::any et std::variant

Marshall Clow entretient libc++ et souhaite parler des extensions à std::search() et string_view. Il dirige LWG

Anthony Williams entretient sa version de la bibliothèque standard de threading. Il souhaite parler des lock_guard variadiques et de shared_mutex.

Walter E. Brown remercie son épouse qui a fabriqué la cravate qu'il porte aujourd'hui. Il est retraité. Ça lui permet de réimplémenter à loisir les parties de la bibliothèque standard qui l'intéressent. Il a beaucoup réfléchi aux concepts, mais il pense qu'on peut raffiner des trucs simples comme numeric_limits. Il souhaite parler de void_t et des raffinements aux bibliothèques numériques, incluant <cmath> (pas <math.h>), donc des trucs comme sample(), clamp(), gcd(), lcm() et les fonctions mathématiques spéciales.

Eric Fiselier travaille sur libc++ depuis deux ans. Il souhaite parler de <filesystem>.

Michael Wong souhaite parler du Parallelism TS

Alisdair Meredith a dirigé LWG dans le passé. Il souhaite parler d'allocateurs.

Bryce Adelstein Lelbach : évolution de la bibliothèque?

Marshall Clow : je réponds en mon nom. Il y a des trucs dans la bibliothèque standard qui pourraient être meilleures. Il y a des techniques que nous souhaitons explorer pour faire un meilleur travail. Il y a des conteneurs qui mériteraient d'être retouchés. Nous oeuvrons sur la STL v2 car il n'est pas question de briser le code existant.

Alisdair Meredith : je pense qu.on devrait foncer dès que C++ 17 sera livré. Ça permettrait d'ajouter les concepts, les contrats et les coroutines, qui peuvent tous changer la manière de programmer, de même que les modules, qui nous permettront de changer les modalités organisationnelles du code.

Bryce Adelstein Lelbach : intervalles?

Casey Carter : ils vont changer nos pratiques, un peu comme les nouvelles boucles for l'ont fait, et nous permettre de réfléchir de manière plus générale et plus abstraite.

Bryce Adelstein Lelbach : retraits?

Stephan T. Lavavej : le standard est trop complexe, alors on réduit la complexité en élagant. Je pense qu'il faudrait mettre bind() aux ordures aussi. CWG a fait un meilleur boulot que LWG ici. Vive les λ! Mort à vector<bool>!

Alisdair Meredith : je veux les intervalles. Je veux de meilleures facilités de traitement de chaînes de caractères, pour gérer UTF-8 convenablement. (applaudissements dans la salle)

Q : les boucles for sur des intervalles peuvent mener à des copies inutiles

Stephan T. Lavavej : j'ai essayé de proposer quelque chose pour réduire ce risque mais ça a été bloqué en plénière. L'irritant était syntaxique. Je vais la ressuciter mais avec une meilleure syntaxe.

Q : craignez-vous de faire des bêtises?

Alisdair Meredith : il faut prendre des risques et être inspirants.

Anthony Williams : on expérimente aussi avec STL v2 et les TS pour développer de nouvelles idées et de nouvelles techniques.

Michael Wong explique ce qu'est un TS. C'est ce qu'on appelait un Technical Report par le passé.

Walter E. Brown : mon premier contact avec ce qui est aujourd'hui un TS était TR1, et tout ce qu'il y avait là-dedans sera dans C++ à partir de C++ 17 (il ne manquait que les fonctions mathématiques spéciales, et elles sont adoptées maintenant). La rétroaction reçue des gens qui ont expérimenté a rendu le langage bien meilleur. Je vous recommande donc d'essayer les TS et de nous donner votre opinion. Walter E. Brown souhaite que min() et max() soient réparés.

: j'aimerais que la STL v2 soit plus cohérente dans son application du Small Buffer Optimization

Stephan T. Lavavej : ce qui est garanti avec vector<T> est que swap sera noexcept et de complexité . Pour cette raison, on ne fera pas cette optimisation pour vector. On peut envisager un small_vector par contre.

Michael Wong : pour std::function, SG14 apporte une std::inplace_function et std::clump()

: les gens ne risquent-ils pas d'avoir peur de changer leur API face à STL v2?

Michael Wong : il y a un consensus fort à l'effet que la STL v2 est prête pour production, disons à .

AM : Herb Sutter a dit qu'il ne pense pas que les TS seront un succès tant que nous ne nous seront pas trompés, car se tromper signifie avoir été suffisamment ambitieux pour prendre des risques.

Howard Hinnant : nous avons expérimenté avec TR1, mais ce document n'était pas assez épeurant.

Stephan T. Lavavej distingue « expérimenter avec l'interface » et « expérimenter avec l'implémentation ».

Arthur O'Dwyer : j'espère que STL v2 aura moins de surcharges d'opérateurs. Je trouve qu'on abuse un peu du concept (il critique la surcharge de '/' pour filesystem)

Casey Carter : c'est la seule chose que nous avons pour fin de notation infixe.

Anthony Williams : dans SG1, on se demande si '|' pourrait permettre d'enchaîner des opérations. C'est une belle syntaxe, efficace visuallement et expressive.

: string_view est efficace mais repose sur une paire pointeur,taille. Pourquoi pas une paire iter,iter?

Marshall Clow : l'inspiration reposait sur des séquences contiguës en mémoire de caractères, pour fins de vitesse

Je dois quitter. Il est environ 14 h 50. Ce fut une semaine enrichissante mais je suis fatigué et il est temps de revenir chez moi. 


Le chemin vers l'aéroport s'est bien déroulé. Mon chauffeur avait un accent très prononcé (beaucoup plus que le mien!) mais était sympathique. Truc amusant : j'ai fait le chemin de l'aéroport à l'hôtel avec Mitch Carlson samedi dernier dans une voiture hybride, et je suis revenu à l'aéroport dans un taxi hybride aussi.

Il y avait peu de gens aux douanes (tant mieux!), mais je me suis fait fouiller comme à l'habitude. Mes cheveux sont épais et les détecteurs de métal pensent toujours que j'ai un truc sur les omoplates. C'est ça ou la craie sur mon ordinateur portable, selon le contexte (il y a moins souvent de la craie ces jours-ci car les écoles tendent à enlever ce vénérable et polyvalent outil qu'est l'ardoise). J'écoute le dernier Marillion (excellent!) en retournant mes courriels et en écrivant ceci. La fatigue frappe. Ce fut une longue semaine.


J'ai bavardé avec im chic type qui participait à ma classe et avec son épouse, qui ne donne pas dans l'informatique mais qui a profité de la semaine pour visiter Seattle. Leur nom m'échappe malheureusement mais ce fut bien agréable. Éventuellement, Michael Wong est arrivé et la conversation a glissé vers ses travaux récents.

Une fois dans l'avion, il se trouve que Michael Wong était mon voisin (un concours de circonstances) alors nous avons bavardé; Michael Wong est un très chic type. Tristement, notre avion a été retardé de plus d'une heure sur le tarmac de Seattle (j'ai appris plus tard que c'était dû à un retard à Vancouver; nous n'aurions pas pu atterrir si nous étions partis plus tôt). Il me racontait ses propres mésaventures de voyage (il en a vécu de spectaculaires en venant à CppCon lui aussi). Nous sommes arrivés à Vancouver avec un solide retard, et il devait transiter plus d'une heure avant moi alors il est parti rapidement à l'arrivée (j'ai su le lendemain qu'il y était arrivé, mais ce fut serré). Nous avons eu droit à un traitement accéléré à Vancouver, ce qui lui a probablement sauvé la peau.

Le reste du voyage s'est déroulé dans une semi-inconscience de grande fatigue. Immense merci à mon chic papa Réal Roy pour être venu me cueillir à l'aéroport et avoir fait de la fin de mon voyage quelque chose de simple.


Valid XHTML 1.0 Transitional

CSS Valide !