À propos de cppcon 2016

Glossaire

Quelques termes que vous verrez ci-dessous :

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

Début du contenu technique

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

Fin du contenu technique

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.

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.

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.

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

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

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.

Q : comment contribuer à SG14?

Michael Wong : commence par la liste de diffusion.

Q : 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.

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

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

What is the basic interface? (1 de 2)

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

• Nous prouvons régulièrement que nos programmes fonctionnent
• Cette preuve jaillit du texte du programme. Ça se lit bien quand le programme est bien écrit
• Parfois, la preuve est erronée, d'où les bogues (plusieurs d'entre eux, du moins)

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

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.

Q : 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.

Q : 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.

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.

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

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.

Q : 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.

Q : 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.

Q : 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.

Q : 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.

Q : 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 $15\%$ à $18\%$ 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é.

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

Q : 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.

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

Q : 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.

Q : 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.

Q : 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.

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

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

Herb Sutter : parce qu'il induisait en erreur.

Q : 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.

Q : 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?

Q : 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.

Q : 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.

Q : 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.

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

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

Herb Sutter : isocpp.org

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

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

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

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

• ... au début, le langage d'assemblage
• ...à la fin des années '70, C
• ... vers le milieu des années '90, C++

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 :

• Essayer de les amener à comprendre le système de types
• Articuler ces idées avec eux :
  • les deux langages ont des systèmes de types statiques, déterminés par la déclaration des objets. Ce type ne change pas pendant l'exécution du programme, indépendamment des valeurs prises (montrer la familiarité)
  • on peut surcharger les opérateurs grâce à ce système de types
  • un type de données est un ensemble de propriétés statiques pour des objets : taille, alignement, ensemble de valeurs valides, ensemble d'opérations (montrer ce que ça signifie en C)
  • un type détermine aussi ce qui ne peut pas être fait avec un objet
  • comment comprendre les transtypages (commencer par C). Entre autres, un tableau est un tableau, pas un pointeur. C'est la décrépitude qui nous coûte cette information, et cette situation est temporaire et locale. Même chose pour les promotions arithmétiques... mais attention aux tableaux passés en paramètre aux fonctions!
  • les tableaux importent aux programmeuses et aux programmeurs C. Attendez un peu avant d'utiliser vector
  • Dan Saks cite Scott Meyers : « Make interfaces simple to use correctly and hard to use incorrectly ». C'est utile peu importe le langage. Il revient sur memcpy(), et montre comment écrire une fonction générique déduisant les types et les tailles des tableaux à copier... en appelant memcpy() correctement, pour faire une démonstration (n'utilisez pas enable_if!)

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)

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 :

• La tension entre « enseigner un langage » et « enseigner avec un langage », éternelle question, a pris de la place. Au fond, en pratique, il faut faire les deux mais la question de l'équilibre est difficile à résoudre
• Avoir accès à des ressources de qualité quand on habite dans une région plus éloignée des grands centres
• Utiliser C++ pour des cours de base, face à la réputation qu'a le langage d'être un « langage d'experts »
• En contrepartie, la difficulté d'avoir des formations de qualité pour les bases du langage, car les présentateurs réputés tendent à donner des formations avancées
• Comment enseigner C++ (il y a des questions là-dedans dont on parle en département chez nous). Il y a des gens qui s'obstinent à enseigner les pointeurs à des débutants, par exemple
• Peut-on aborder des questions d'échelle, de gros systèmes, dans un contexte académique? (je pense que c'est difficile, faute de ressources, mais Hartmut Kaiser pense que le code ouvert ouvre des avenues en ce sens)
• Comment améliorer l'enseignement des techniques de gestion d'erreurs
• La question de la qualité des manuels, qui n'est typiquement pas terrible, etc.

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

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)

Q : 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.

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> où 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.

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

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

Q : 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.

Q : 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.

Q : 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.

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

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)

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

Q : 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!

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 $10\%$ 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 $24 \times 21$ 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 $24 \times 21 + 1$ fois (le $+1$ 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 »

Q : 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...

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.

Q : 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.

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

Q : 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.

Q : 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.

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.

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.

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

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

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.

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

CodeCompass – Daniel Krupp

C'est un outil de visualisation graphique du code.

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.

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.

Orbits – Sandeep Gupta

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

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

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

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.

Qt Creator – Giuseppe D'Angelo

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

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.

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.

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.

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.

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

Q : 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.

Q : 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.

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.

Q : 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.

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

Ryan Quinn : je me cache 

Q : 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.

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.

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.

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.

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 :

• Une portée délimitée par un bloc (typiquement sur la pile). Ça fonctionne tout seul. Ça doit couvrir approximativement $80\%$ des cas
• Des objets  alloués dynamiquement, qui ont leur propre durée de vie indépendamment du bloc d'origine. Pour ça, on a des conteneurs et unique_ptr
• Des objets qui ont une fin de vie indéterminée. Pour ça, on a shared_ptr

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 :

• Relation has-a, modélisée par composition
• Relation has-a découplée, où l'objet est crée de manière tardive, ou utilisé de manière indirecte et susceptible de changer de type effectif. On a unique_ptr. Herb Sutter donne l'exemple de pImpl, qui se modélise bien par un unique_ptr sur un type incomplet, ou à la limite un const unique_ptr si on ne le veut pas déplaçable
• Représenter un bloc de données de taille dynamique peut se faire avec un unique_ptr<T[]> ou un vector<T> selon les besoins
• Représenter un arbre n-aire de noeuds, de manière à ce que les noeuds soient détruits lorsqu'ils ne sont plus requis peut se faire avec un vector<unique_ptr<Noeud>> par noeud, et un unique_ptr<Noeud> comme racine
  • ... le problème est que détruire l'arbre fera exploser la pile

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 $1$. Cela garantit qu'une récursion sera de complexité $O(n)$ 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)

Q : 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.

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.

Q : 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é $O(1)$. 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()

Q : 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 à $99\%$.

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.

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