Je reviens de la conférence C++ On Sea, dans la riante bourgade de Folkestone, à côté de Douvres. Mon employeur bien aimé nous ayant signifié qu'il voulait bien payer la conf mais qu'il fallait quand même bosser un peu de temps en temps, nous avons eu droit à 1 journée chacun, et j'ai sélectionné le vendredi.
Alors, l'endroit est surprenant. En arrivant sur la place en haut de la falaise, j'ai vu une sorte de petit kiosque abritant un café. Eh bah c'est là dedans, car il faut descendre un escalier, et on se retrouve dans un décor de vieux pub avec une vague odeur de moisi en prime, et de gigantesques salles à flanc de falaises avec vue imprenable sur la mer (enfin, la vue aurait été imprenable si il ne flottait pas comme ruminant qui urine).
Mais honte à moi de me focaliser sur de basses considérations matérielles, nous étions venus pour qu'on nous cause de C++, nous avons été servis !
D'abord, une présentation de l'état de l'art en ce qui concerne les modules C++20 et l'intégration aux outils de build. Eh bah on n'est pas sortis des ronces. En effet, il faut en fait précompiler chaque module que l'on utilise, en particulier des logiciels tiers, et ceci pour chaque combinaison
Car les modules, qui semblent ne fournir pas grand chose de plus que les en-têtes précompilées des années 2000, ajoutent beaucoup de complexité, car il faut aller construire la fameuse en-tête précompilée pour chaque combinaison d'options de compilation que l'on utilise pour les unités de translation qui incluent ledit module, et s'assurer que l'on construit tout bien dans l'ordre. Quand aux bibliothèques qui ne fournissaient qu'un fichier d'entête, voilà que maintenant il faut compiler à la fois le module, et le fichier objet correspondant, puisque le module compilé ne contient pas tout le code nécessaire. Complexité++, avantages--, c'est ce que j'avais retenu, mais cette conférence le confirme.
Ensuite, on est montés dans les tours avec une présentation sur la manière d'écrire une fonction "max" de plus en plus subtile. J'ai appris avec joie l'existence de std::cmp_less qui permet d'effectuer correctement des comparaisons avec des types entiers différents. L'orateur a ensuite vrillé avec l'introduction d'un meilleur std::common_type, puis d'un type template spécial pour représenter un temporaire, dans le but de résoudre un problème un peu subtil lorsque l'on fait par exemple le max d'un min, et qui peut causer le retour d'une référence sur un temporaire. L'orateur s'est ensuite lâché en critiquant la décision du C++ d'introduire les références, mais Rust en a pris pour son grade aussi.
Troisième présentation, cette fois ci beaucoup plus soft, sur les styles de codage, et en particulier l'application bête et méchante de certaines règles mal comprises. Rien de révolutionnaire, mais plaisant tout de même, et j'en ai retiré une idée intéressante, qui est d'automatiser au maximum son style de codage. Ce qui nous amène naturellement à la présentation suivante…
Sur les outils clang qui permettent de visualiser, de chercher voire de réusiner en se servant de l'AST d'un programme. L'orateur a démontré l'inadéquation des outils syntactiques de type grep et sed pour travailler avec du code, et comment clang-query peut permettre de chercher des motifs particuliers dans une base de code à l'aide d'une requête s'appuyant sur l'AST. Cerise sur le gâteau, Godbolt, l'IDE en ligne ultime, permet d'afficher l'AST d'un programme, ce qui aide à préparer sa requête. L'intégration à clang-tidy pour ajouter de nouveaux outils de reformatage ou de vérification statique est possible, mais nécessite quand même de forker et recompiler clang-tidy (ou d'écrire du python, mais c'est impensable).
Et finalement, la présentation de fin, Klaus Iglberger, gourou du C++, qui nous a fait un topo sur le design et sur son nouveau cheval de bataille, l'effacement de type. Sa démonstration, basée sur l'implémentation du bon vieux problème de l'affichage des formes géométriques via l'héritage à la papa, puis l'approche fonctionnelle utilisant std::variant, puis l'approche sémantique de valeur et effacement de type, était brillante.
Ça s'est fini au pub (un vrai pub, cette fois ci), puis dans le train de retour vers Londres à causer avec tout un tas de gourous très sympas.
On y retournera !
# Ah les modules
Posté par Julien Jorge (site web personnel) . Évalué à 10 (+9/-0).
Les modules c'est un peu l'IPv6 du C++, la promesse d'un futur meilleur qui n'arrive pas, depuis environ 20 ans. J'ai du mal à croire que leur utilisation va se généraliser ne serait-ce que dans la décennie à venir.
Tiens, quelle était la tendance sur les sujets de gestion des dépendances là-bas ? Voilà un sujet très tendance qui est loin d'être évident aussi.
J'ai l'impression que le C++ se trouve dans une situation bien bancale depuis quelques années. D'un côté ça pousse fort pour « moderniser » le langage et ajouter des trucs à la lib standard, mais de l'autre côté on aura toujours à supporter les bases. Au final on a pas loin de zéro simplification : Par exemple il faut toujours comprendre la syntaxe du
forde base, et sûrement savoir ce qu'est un itérateur, mais il faut aussi maintenant connaître lerange-based-foret ses subtilités, ainsi que<range>et ses pièges… Ça ne fait que s'empiler.Et c'est un peu dommage. À force de vouloir tout mettre parce que tel autre langage fait ceci, ou un autre fait cela, on se retrouve avec une sorte de Rust--, un Python-mais-pas-aussi-concis, et des temps de build qui montent, qui montent, qui montent :/
[^] # Re: Ah les modules
Posté par alkino . Évalué à 2 (+0/-0).
Moi ma grande déconvenue récemment avec C++ ça a été les
std::pmr::vectorça fixe pleins de trucs mais jamais personne ne va les supporter…# Les modules
Posté par arnaudus . Évalué à 4 (+1/-0).
😱 😱 😱 😱 😱 😱 😱 😱 😱 😱 😱 😱 😱
Est-ce qu'on connait au moins un langage ou un écosystème qui ait réussi à gérer le problème de manière satisfaisante? J'imagine pourtant qu'il y a des milliers de gens qui bossent là-dessus, et en 2024, on en est à choisir entre
Après, je veux bien que C++ doive gérer une longue histoire et que ça n'est probablement pas le meilleur contexte pour mettre au point un système de dépendances moderne, mais y a-t'il un seul langage qui accepte quelque chose dans le style de
module(toto, 0.9.1, 1.2)?[^] # Re: Les modules
Posté par Lutin . Évalué à 2 (+0/-0).
Ça ressemble pas mal au cargo.toml de rust (et aux whatmille gestionnaires de plugins *vim mais c'est pas vraiment un langage).
[^] # Re: Les modules
Posté par Faya . Évalué à 2 (+0/-0).
Soit je n'ai pas compris la question, soit la plupart des gestionnaires de dépendances proposent ça. Un moyen de fixer la version d'une dépendance entre 0.9.1 et 1.2. Node/npm, Python/pip, Rust/cargo, PHP/Composer… Par contre ce sont tous des langages de script, je ne sais pas si ça joue.
[^] # Re: Les modules
Posté par arnaudus . Évalué à 3 (+0/-0).
Du coup, tu veux dire qu'il faut définitivement séparer le langage de programmation de la gestion des dépendances, et qu'il n'y a pas d'autre solution? Je n'ai pas la prétention de connaitre tous les systèmes existants, mais tout ça semble fonctionner en deux temps: le code lui même appelle un module ou une bibliothèque de manière neutre (#include), et c'est à l'environnement de compilation ou d'exécution de se débrouiller pour que ça soit le toto avec la bonne version qui soit appelé, bonne version qui se retrouve quelque part dans le README, dans les commentaires du code, dans le ./configure, ou dans un script qui te fait un paquet.
Il n'y a peut-être pas de solution, ou on peut même peut-être prétendre que ça n'est pas au code source de gérer les versions des dépendances, mais je trouve que les solutions existantes sont anachroniques et totalement décalées par rapport à la réalité des contraintes de développement et de diffusion de programmes informatiques.
[^] # Re: Les modules
Posté par alkino . Évalué à 2 (+0/-0).
https://spack.io le fait mais c'est un peu le bazooka pour la mouche.
# Modules et visibilité
Posté par T_T_T . Évalué à 1 (+0/-0).
Pour ma part, j'ai surtout espéré des modules une fine gestion de la visibilité des classes, fonctions…
Là où aujourd'hui on utilise des
namespace detailsou autre; finalement une convention de nommage.Est-ce que je me trompe? Est-ce que c'est "au point"?
[^] # Re: Modules et visibilité
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Ça se fait avec la visibilité des symboles ça (compiler avec -fvisibility=hidden et ajouter des déclarations de visibilité à chaque classe ou méthode qui doit être accessible de l'extérieur). Mais c'est vrai que c'est dommage de devoir recourir à des attributs non standards pour le faire.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.