Le 15 juin 2019 a eu lieu la première édition de CPPP, une journée entière de conférences internationales axées sur le langage de développement C++. Retour sur une sélection de talks dont l’objectif commun était de faire progresser les développeurs débutants comme confirmés en C++. 

1 – Emotional Code – Kate Gregory

Derrière ce titre qui semble inviter au sentimentalisme se cache en réalité une réflexion très pertinente à propos de l’impact de notre état mental sur le code que nous produisons. 

Insécurité, arrogance, colère, égoïsme, paresse, désinvestissement, stress, sont autant de mots clés qui mènent à du code obscure, peu documenté, peu voire pas testé, réinventant la roue, contenant des commentaires dirigés contre d’autres développeurs, … Cette liste est non-exhaustive.

Kate Gregory met ainsi en avant, exemples à l’appui, que nos émotions impactent notre production et que la première étape pour en limiter les conséquences est d’en prendre conscience.en est la prise de conscience.

La seconde étape est de cultiver un état d’esprit plus positif – empathie, générosité, confiance, bienveillance – et d’en faire bénéficier le code en faisant évidemment tout le contraire de ce qui est listé au paragraphe précédent. Mais pas uniquement. Le cadre social est une autre des cibles puisque l’idée est également d’apprendre à détecter les comportements toxiques, y compris chez soi-même.

De nombreuses questions et remarques ont suivi, relatant souvent d’expériences personnelles, et démontrant que le sujet avait touché une zone sensible dans l’audience.

Nous avons beau apprendre les meilleures pratiques et techniques du monde pour être les plus performants, seuls, devant nos écrans, au final nous travaillons dans un cadre qui implique énormément de partage de code.

Qu’il s’agisse de reprendre ou de léguer du code, de débugger du code qui ne nous appartient pas ou que d’autres corrigent le nôtre, de développer des librairies internes qui seront utilisées par d’autres équipes, de mettre son code à disposition du monde entier, la qualité du code ne se résumera pas seulement aux performances et à l’ingéniosité de celui-ci mais aussi au sentiment qu’il laisse à la lecture et à l’utilisation.

« There is no neutral code. »
(Il n’y a pas de code neutre.)

2 – Améliorez votre C++ avec les algorithmes de la STL –  Mathieu Ropert

Mathieu Ropert travaille actuellement chez Paradox Interactive. Son parcours est varié et son blog mérite un détour.

Le C++ ne nous habitue pas nécessairement à avoir le même réflexe qu’en Python, de chercher la librairie à ‘importer’ et qui résoudra la problématique. Nous aurions au contraire même parfois tendance à réinventer la roue. Pourtant le langage dispose dans sa librairie standard d’une bonne collection d’algorithmes. 

Après un rappel des différents concepts autour des itérateurs, démarre une présentation illustrée d’algorithmes disponibles dans le header éponyme. Tous ? Non. Il y en a un bon nombre. Le conférencier invite d’ailleurs à visionner la performance de Jonathan Boccara qui présente les 105 algorithmes dont dispose la STL jusqu’au C++17. Ici l’objectif est d’éveiller l’intérêt et d’apporter quelques subtilités. Le ‘pointeur sur la fin’ se nomme une ‘sentinelle’, std::remove n’efface rien, zoom sur std::not1, std::lower_bound, std::rotate,  std::stable_partition, pour ne citer que ceux-la. La séance s’est terminée sur une présentation rapide du chaînage des algorithmes sur les ranges en C++20.

3 – Adding a new clang-tidy check by the practice – Jeremy Demeule

Jeremy Demeule est ingénieur logiciel chez Murex – https://twitter.com/jeremydemeule

Dans cette conférence, il a abordé l’utilisation de Clang-tidy, un analyseur de code statique, utilisé notamment pour moderniser du code. Clang-tidy est basé sur clang et propose une énorme liste de vérifications ainsi que la possibilité de remplacer du code.

La présentation allait cependant plus loin en proposant de coder en direct une nouvelle vérification de A à Z. Comprendre le code d’origine, comprendre le code cible, créer le ‘matcher’ avec clang-query et enfin créer le ‘fix’ avec clang-tidy.

4 – Merci le compilo – Serge Guelton

Serge Guelton travaille sur LLVM pour RedHat.

En guise d’introduction, il nous rappelle que ce qui garantie la rapidité du C++, ce n’est pas le Standard mais le compilateur. Effectivement, si on ne devait donner qu’un exemple, il n’y a qu’à partir du C++17 que le Standard édicte qu’une élision de copie doit avoir lieu lorsqu’un nouvel objet est retourné directement par une fonction. Cependant, g++ n’a pas attendu cette version et optimise ‘naturellement’ les constructions et copies d’objets, même avec l’option -O0. Il faut explicitement lui donner l’option -fno-elide-constructors pour qu’il ne le fasse pas.

Ainsi, le compilateur fait bien plus qu’obéir au standard en intervenant grandement et souvent sans nous le demander dans les performances des applications.

Il est donc tentant de se concentrer sur la maîtrise du langage et de confier au compilateur l’optimisation ‘générale’ avec -O2, -O3. Cependant, plus les contraintes techniques imposées sont fortes, plus il est important de ne rien laisser à la «magie».

Serge Guelton entame ainsi la description d’une petite sélection parmi deux milles et quelques flags de compilation d’llvm, avec comme fil rouge ces compromis auxquels nous devons parfois faire face. Sans surprise il y a presque systématiquement la performance d’un coté de la balance alors que de l’autre se trouve la taille du programme (-g3), la précision mathématique (-ffast-math), la portabilité (-march=native) ou encore la sécurité (-fsanitize=address). 

Nous avons également eu un aperçu, entre autre, de la PGO (Profil Guided Optimization), qui consiste à faire tourner le programme sur des cas représentatifs puis à le recompiler à l’aide de ce profilage ainsi que la LTO (Link Time Optimization), qui intervient sur les temps de compilations, les seuils d’inlining, les seuils de déroulement de boucle ou encore la simplification des vtables.

5 – Élégance, style épuré et classe – Loic Joly

L’observation de base se situe au niveau des règles de générations par le compilateur des constructeurs et opérateurs d’assignation, appelées ici les ‘fonctions spéciales‘.

En décidant de créer une classe, on se confronte dès le début à ces questions d’ordre technique. Qu’est-ce que je définis ? Qu’est-ce que je préviens ? Qu’est-ce que je délègue au compilateur ?

Une solution simple est de décider de n’en définir aucune (règle du zéro), et d’être ainsi certain de laisser complètement le contrôle au compilateur, ou de les définir toutes (règle des cinq). Mais est-ce si simple ?

Loic Joly nous a proposé une vision liant cette problématique avec des rôles prédéfinis que l’on peut associer aux classes.

• Les classes vides : Sans état et sans donnée membre, telles que les classes de traits, ou de policies. Ici, nul besoin de définir quoi que ce soit.
• Les agglomérats : Des données groupées, publiques, sans comportement. Ici, nul besoin de définir quoi que ce soit également, sinon un constructeur.
• Les classes à sémantique de valeur : Par exemple une chaîne de caractère ou une date. Ce sont des abstractions qui permettent de réfléchir simplement et à ce titre, nombre de ces classes existent dans le langage et la STL. Ces classes sont à minima copiables et constructibles par défaut.
• Les classes à sémantique de référence : Elles contiennent de la donnée allouée ailleurs et sont sujettes aux références ‘pendouillantes’ et donc dangereuses.
• Les classes d’une hiérarchie polymorphe : Elles dépendent des fonctions spéciales définis par la classe de base.
• Les classes de mécanisme : L’action y est plus importante que la valeur. Ces classes sont par exemple cout ou socket. Ici les fonctions spéciales sont plus complexes. Ces classes ont souvent de la ressource à gérer (RAII) et s’il fait rarement sens de les copier, il est envisageable de les déplacer. Devoir écrire de telles classes est cependant rare.

Il est intéressant de comprendre que choisir un rôle clair lors de la définition d’une classe peut être un soutien lorsqu’il s’agit d’en implanter.

En conclusion

Avec ses sujets variés, l’énergie des organisateurs et le soin apporté au confort de l’audience, cette première édition de CPPP est un nouveau moteur bienvenu d’échanges de savoir, d’idées, de sujets de réflexions, d’invitations à coder mieux et surtout à devenir de meilleures personnes. Le bilan laisse très enthousiaste pour la prochaine édition.

Source photo : La Fille d’à Côté via Twitter