fmtlib fmt arrive en tête de GitHub Trending, mais la véritable histoire est celle de la maintenance
fmtlib fmt a atteint la première place d’un instantané de la liste GitHub Trending daté du 3 septembre 2026, malgré l’absence de nouvelle version ce jour-là.
Cette distinction est importante. Le classement provenait d’un agrégateur suivant GitHub Trending, mais son enregistrement ne fournissait ni heure de capture vérifiée ni hausse quotidienne du nombre d’étoiles. GitHub ne publie pas non plus d’archive permanente et vérifiable de manière indépendante pour chaque liste Trending.
La plus récente version stable était fmt 12.2.0, publiée le 16 juin, selon l’historique des versions du projet. Elle a ajouté une interface C11, étendu la prise en charge des modules C++ et poursuivi le travail de performance de la bibliothèque.
L’événement n’est donc pas une histoire de lancement conventionnelle. Il montre qu’une bibliothèque d’infrastructure établie peut soudainement attirer une large attention plusieurs mois après une version.
Cette attention ravive aussi une question importante pour les équipes C++. Si std::format et std::print existent désormais, pourquoi la bibliothèque indépendante qui a contribué à les façonner reste-t-elle aussi visible ?
Le classement est réel, mais sa cause n’est pas vérifiée
L’événement vérifié est une position dans les tendances, pas une annonce produit en septembre.
L’instantané BettaFish fourni a placé fmtlib/fmt en première position de sa liste GitHub Trending du 3 septembre. Toutefois, l’agrégateur n’a pas indiqué d’heure de publication précise, d’intervalle de classement ni de nombre quotidien d’étoiles.
Ces omissions empêchent d’expliquer avec certitude cette hausse. Une publication sur les réseaux sociaux, un projet en aval, un tutoriel populaire ou l’activité courante sur GitHub ont pu y contribuer. Aucun facteur déclencheur unique ne peut être établi à partir du seul classement.
Il n’existe pas non plus de version correspondante datée du 3 septembre. La page des versions du projet identifie la 12.2.0 comme la dernière version stable disponible dans les sources vérifiées.
Cette version est sortie plus de deux mois avant le classement observé. Présenter cette apparition dans les tendances comme une sortie de version fusionnerait deux événements distincts et créerait une chronologie erronée.
GitHub Trending mesure lui-même l’attention, pas l’adoption en production. Une position élevée peut refléter une évolution rapide de l’intérêt de la communauté, mais elle ne révèle ni téléchargements de dépendances ni versions déployées.
La liste ne fournit pas non plus les détails méthodologiques nécessaires à des comparaisons rigoureuses. GitHub décrit les dépôts comme étant tendance sur une période sélectionnée, mais n’expose pas la formule complète du classement.
Un dépôt peut donc progresser sans événement marquant unique. Les développeurs peuvent le découvrir via des mises à niveau de paquets, de la documentation, des discussions sur les compilateurs ou le graphe de dépendances d’un autre projet.
Ce schéma est particulièrement plausible pour fmt. Le code de formatage se trouve sous les systèmes de journalisation, les outils en ligne de commande, les bases de données et les services, où il reste souvent invisible pour les utilisateurs finaux.
Le dépôt comptait environ 23 500 étoiles et 2 900 forks dans une vue GitHub récemment indexée. Ces totaux établissent l’existence d’un public, non l’apparition d’un projet sorti de nulle part.
Son historique couvre également des milliers de commits. Une base de code mature peut revenir dans Trending lorsque le travail de maintenance accumulé devient à nouveau pertinent pour les développeurs.
La conclusion la plus prudente est limitée mais utile. fmtlib fmt a connu un pic notable d’attention sur GitHub le 3 septembre, tandis que sa cause immédiate reste non vérifiée.
Cette incertitude ne vide pas le classement de son sens. Elle déplace le récit d’un lancement supposé vers les raisons pour lesquelles cette bibliothèque continue de refaire surface.
fmtlib fmt 12.2 étend sa portée au C
La version 12.2 compte parce que fmt s’est étendu au-delà de son rôle C++ familier tout en continuant d’optimiser le travail quotidien de formatage.
Le changement de périmètre le plus important est fmt-c, une interface C11 fournie via l’en-tête fmt/fmt-c.h. Elle utilise _Generic, une fonctionnalité C11 qui sélectionne une expression selon le type d’un argument.
Cette conception apporte un formatage guidé par les types au C sans prétendre que le C possède les templates du C++. Les développeurs appellent fmt_print avec des chaînes de formatage à accolades et des valeurs ordinaires.
Le printf traditionnel dépend d’une chaîne de format dont les spécificateurs de conversion doivent correspondre aux arguments qui suivent. Une incompatibilité peut produire des avertissements, une sortie incorrecte ou un comportement indéfini.
La nouvelle interface vise à détecter davantage d’erreurs grâce à la répartition fondée sur les types. Elle donne également aux programmeurs C accès au modèle de formatage déjà familier à de nombreux utilisateurs de C++ et Python.
Il s’agit d’une extension, non d’un remplacement de l’identité centrale de fmt. Le projet se présente toujours comme une alternative open source à stdio en C et iostreams en C++ dans sa présentation du projet.
La version 12.2 a également introduit une cible CMake distincte, fmt::fmt-module. Une cible CMake regroupe les exigences de compilation afin que les projets en aval puissent utiliser une bibliothèque de manière cohérente.
Cette cible prend en charge les modules C++20, qui permettent aux compilateurs de traiter des interfaces déclarées au lieu d’analyser à répétition des en-têtes textuels. fmt a aussi ajouté une couverture d’intégration continue pour les builds basés sur les modules.
Les modules promettent depuis des années des frontières plus propres et un meilleur comportement de compilation. Leur adoption réelle reste inégale, car la prise en charge des compilateurs, de la bibliothèque standard et des systèmes de build doit s’aligner.
Une cible maintenue offre aux équipes une voie d’intégration prise en charge. Elle ne garantit pas que chaque combinaison de chaînes d’outils se comportera de manière identique.
Le travail de performance est resté central. La version a activé par défaut le cache de recherche Dragonbox complet, sauf lorsque les builds optimisent explicitement la taille binaire.
Dragonbox est un algorithme qui convertit des valeurs binaires à virgule flottante en texte décimal. Cette conversion intervient dans les journaux, la sérialisation, les diagnostics, les tableaux de bord et les logiciels scientifiques.
Le projet fait état d’une amélioration de vitesse d’environ 10 à 25 % grâce à ce changement de cache. Son benchmark publié a mesuré 22,07 nanosecondes par double pour la configuration avec cache complet.
La configuration compacte a mesuré 29,55 nanosecondes dans le même environnement documenté. Il s’agit de benchmarks produits par le projet, sur un Apple M1 Pro avec Clang 17.
Ils montrent le mécanisme dans cet environnement de test, et non une accélération universelle des applications. La plupart des programmes ne consacrent qu’une partie de leur temps d’exécution au formatage de valeurs à virgule flottante.
La version 12.2 a également signalé une amélioration d’environ 3 % du formatage d’entiers. Les opérations d’ajout en masse ont amélioré la sortie via des itérateurs d’insertion en fin utilisés avec des conteneurs et des chaînes personnalisées.
La taille des builds de débogage a également été prise en compte. Le projet indique que son test de gonflement est passé d’environ 200 kilo-octets à 85 kilo-octets dans la configuration concernée.
D’autres changements concernaient le formatage sans perte des chemins du système de fichiers, std::unexpected, les surcharges println stylisées et les arguments de largeur positionnels pour l’API compatible printf.
Aucun de ces éléments n’explique à lui seul un classement de septembre. Ensemble, ils montrent un projet qui étend sa surface sans abandonner son travail de maintenance.
Le C++ standard exerce une pression sur fmt sans le remplacer
La concurrence centrale oppose fmt au formatage de la bibliothèque standard, mais les deux restent liés plutôt que nettement opposés.
Le C++ moderne inclut désormais std::format, qui produit du texte formaté, et std::print, qui envoie une sortie formatée vers un flux. Cela réduit la nécessité d’une dépendance externe.
Le détail historique important est que fmt a contribué à établir cette direction. Le projet s’identifie comme une implémentation de std::format de C++20 et de std::print de C++23.
Victor Zverovich, mainteneur de fmt, est également l’auteur de la proposition qui a introduit la fonctionnalité moderne de formatage dans le standard. La proposition de formatage a explicitement développé une alternative plus sûre à la sortie formatée traditionnelle.
La standardisation modifie la décision d’adoption au sein d’une base de code. Les équipes peuvent préférer une fonctionnalité fournie par leur compilateur et leur bibliothèque standard plutôt que de gérer un paquet supplémentaire.
Cette option devient attrayante dans les environnements conservateurs. Moins de dépendances peuvent simplifier l’examen de sécurité, les vérifications de licences, les mises à jour et la reproductibilité des builds à long terme.
La voie standard conserve toutefois des contraintes. La disponibilité des fonctionnalités dépend des versions de compilateurs, des implémentations de bibliothèque standard et du mode de langage choisi par chaque projet.
Une équipe prenant en charge d’anciennes chaînes d’outils d’entreprise ne peut pas supposer que chaque cible dispose d’une prise en charge complète du formatage C++20 ou C++23. Les produits multiplateformes avancent souvent au rythme de leur environnement pris en charge le plus ancien.
fmt peut fournir une interface plus cohérente entre ces environnements. Il peut aussi publier des améliorations sans attendre le cycle pluriannuel de standardisation et de distribution des chaînes d’outils.
La bibliothèque propose des API qui dépassent une lecture stricte de la surface standard. Elles incluent le formatage de plages, les couleurs et styles de texte, les utilitaires de fichiers de sortie et des intégrations conçues selon son propre calendrier de versions.
L’API C11 de la version 12.2 accentue cette différence. std::format appartient au C++, tandis que fmt propose désormais un modèle de formatage couvrant les projets C et C++.
Cela ne rend pas fmt automatiquement préférable. Chaque dépendance crée du travail de mise à niveau, des tests de compatibilité et une exposition aux changements en amont.
L’intégration de fmt directement au code source peut compliquer les builds lorsqu’une autre dépendance embarque une version différente. Les systèmes à liaison dynamique doivent aussi prendre en compte la compatibilité de l’interface binaire applicative.
La bibliothèque standard offre un autre type de stabilité. Ses fonctionnalités suivent des spécifications publiées, et les développeurs peuvent s’attendre à de longues périodes de support une fois les implémentations arrivées à maturité.
Pourtant, la standardisation ne fige pas la pertinence du projet d’origine. Elle peut transformer la bibliothèque indépendante en laboratoire en amont pour les idées d’implémentation et les expérimentations de performance.
Cette relation crée le renversement central de l’article. Le succès dans le standard pourrait sembler rendre fmt inutile, mais il valide aussi les choix de conception de fmt.
Le classement de septembre suggère que les développeurs reconnaissent toujours le projet en amont comme un outil actuel. Il n’établit pas combien le choisissent plutôt que std::format.
Une décision utile commence donc par les contraintes. Les équipes devraient comparer les versions minimales des compilateurs, les fonctionnalités requises, la politique de dépendances et les performances mesurées de l’application.
Elles ne devraient pas considérer un rang Trending comme une preuve technique. Elles ne devraient pas non plus supposer que la standardisation a supprimé toutes les raisons d’utiliser la bibliothèque d’origine.
Ce que les benchmarks de fmt ne prouvent pas
fmt publie des chiffres de performance convaincants, mais les développeurs doivent distinguer les tests de formatage ciblés des résultats à l’échelle d’une application entière.
Le README du projet inclut un benchmark comparant plusieurs méthodes de formatage. Dans sa configuration documentée, fmt 12.1 a terminé le test en 0,44 seconde.
Le même test a enregistré 0,66 seconde pour printf, 1,63 seconde pour std::ostream et 3,89 secondes pour Boost Format. Le benchmark a formaté deux millions d’enregistrements vers /dev/null.
Ces mesures étayent une affirmation limitée sur les opérations et l’environnement testés. Elles ne montrent pas que remplacer une API réduira la latence totale d’une application dans la même proportion.
Les charges de travail en production comprennent l’allocation, la synchronisation, les systèmes de fichiers, les opérations réseau, l’analyse et la logique métier. Le formatage peut dominer certains pipelines de journalisation tout en étant à peine perceptible ailleurs.
La propriété du benchmark compte également. Les chiffres proviennent du projet fmt et de ses dépôts de benchmarks associés, et non d’un laboratoire indépendant.
La méthodologie est disponible, ce qui donne aux développeurs un moyen de la reproduire. La reproductibilité a plus de valeur que la répétition d’un titre sur les performances sans contexte.
Les équipes devraient tester des chaînes de format représentatives, des types d’arguments, des options de compilateur et des destinations de sortie. Un microbenchmark qui ignore la sortie ne peut pas modéliser toutes les charges de travail liées aux fichiers ou à la console.
Le temps de compilation mérite la même prudence. Le test de gonflement publié par fmt génère 100 unités de traduction et appelle chaque méthode de formatage à plusieurs reprises.
Le projet indique un temps de compilation optimisée de cinq secondes pour une révision testée de fmt. Il mentionne 1,6 seconde pour printf et des résultats bien plus longs pour les iostreams et Boost Format.
Cette comparaison explique pourquoi la structure des en-têtes et l’instanciation des templates comptent. Elle ne prédit pas le temps de compilation d’un vaste service utilisant des en-têtes précompilés, des unity builds ou beaucoup de code généré.
La version 12.2 comporte également les risques de migration habituels. De nouvelles cibles, de nouveaux formateurs et de nouveaux chemins de performance interagissent avec des chaînes d’outils que les mainteneurs ne peuvent pas entièrement contrôler.
Les rapports d’incidents publics illustrent cette limite. Un rapport de 2026 a soulevé une préoccupation liée à l’encodage concernant EBCDIC et d’autres jeux de caractères d’exécution non compatibles avec ASCII.
Un incident n’est pas la même chose qu’une vulnérabilité confirmée. Il montre que les affirmations de portabilité nécessitent des tests au-delà des environnements UTF-8 grand public.
Le journal des modifications non publié pour la 12.2.1 apporte un autre signal utile. Il répertorie des correctifs pour un blocage sur pipe fermé, le formatage de caractères entiers, les durées à virgule flottante et plusieurs cas d’intégration.
C’est normal pour une bibliothèque active. Cela démontre aussi pourquoi les équipes de production devraient suivre les versions correctives plutôt que d’adopter une version majeure ou mineure une fois pour toutes.
Le projet a ajouté des artefacts de publication, une provenance de chaîne d’approvisionnement, une analyse CodeQL et une politique de sécurité durant le cycle 12.2. Ces mesures améliorent les informations accessibles aux utilisateurs en aval.
Elles n’éliminent pas le risque lié aux dépendances. Les équipes ont toujours besoin de verrouillage de versions, de surveillance des vulnérabilités, de builds reproductibles et de validation sur les compilateurs pris en charge.
Les groupes d’ingénierie peuvent faciliter ce travail en conservant les décisions de mise à niveau et les preuves de test dans une base de connaissances technique consultable. L’objectif est la traçabilité, pas le volume de documentation.
La lecture sceptique est donc simple. fmt dispose d’éléments techniques crédibles, mais ses meilleurs chiffres restent spécifiques aux charges de travail et en partie auto-déclarés.
Une infrastructure mature peut devenir tendance sans lancement
La position de fmt montre comment l’attention des développeurs peut redécouvrir une infrastructure qui a déjà influencé l’écosystème qui l’entoure.
Les applications grand public deviennent généralement tendance autour de lancements visibles. Les dépôts d’infrastructure suivent souvent un rythme différent, car les développeurs les rencontrent à travers des changements de dépendances et des problèmes techniques.
Une bibliothèque de journalisation peut révéler fmt via un message d’erreur. Une mise à niveau du compilateur peut exposer une macro ou une surcharge incompatible. Une migration de build peut pousser une équipe à reconsidérer une intégration header-only.
Chacune de ces voies peut diriger des développeurs vers le dépôt sans produire d’annonce coordonnée. Cela rend les pics d’intérêt plus difficiles à attribuer, mais pas moins pertinents.
La liste des utilisateurs connus de fmt couvre des bases de données, des terminaux, des jeux, des systèmes d’infrastructure et des outils pour développeurs. Le projet cite notamment ClickHouse, Envoy, PyTorch, Windows Terminal et spdlog parmi de nombreux exemples.
Cette liste est maintenue par le projet ; elle ne doit donc pas être lue comme un recensement exhaustif des dépendances. Elle illustre néanmoins la façon dont le code de formatage circule à travers diverses couches logicielles.
L’attrait de la bibliothèque part d’un problème banal. Les programmes transforment constamment des valeurs typées en texte pour les utilisateurs, les journaux, les diagnostics, les fichiers et les messages réseau.
Les E/S formatées de C sont concises, mais font reposer la responsabilité sur les spécificateurs de conversion. Les iostreams de C++ offrent un comportement fondé sur les types, mais peuvent devenir verbeux et transporter un état de formatage.
Le formatage à accolades propose une troisième voie. La chaîne de format décrit le placement et la présentation, tandis que les arguments typés restent des valeurs distinctes.
La vérification à la compilation peut rejeter certaines combinaisons invalides avant l’exécution d’un programme. C’est particulièrement utile dans la journalisation, où des chemins d’erreur rarement exécutés peuvent autrement masquer des erreurs.
L’extensibilité compte également. Un projet peut définir la façon dont son propre type doit être formaté et réutiliser ce comportement pour la journalisation comme pour les sorties destinées aux utilisateurs.
La bibliothèque standard couvre désormais une grande partie de ce terrain. fmt continue de rivaliser grâce à sa portabilité, à des ajouts plus récents et à son rythme de publication.
La prise en charge de C dans la version 12.2 élargit à nouveau le public. Les projets mêlant plusieurs langages peuvent évaluer une approche commune du formatage sans convertir leurs composants C en C++.
Ce changement met aussi la pression sur les autres approches de formatage. printf reste omniprésent, stable et disponible presque partout, mais sa syntaxe et son comportement variadique présentent des risques bien connus.
Les bibliothèques d’enrobage C peuvent améliorer la sécurité grâce à des annotations de compilateur ou à des interfaces générées. fmt-c applique plutôt la sélection générique C11 et la syntaxe de formatage existante du projet.
Il reste impossible de savoir si cette approche connaîtra une adoption significative en C. Le résultat Trending de septembre mesure la curiosité, pas l’utilisation durable de la nouvelle API.
Les données des gestionnaires de paquets offriraient un signal d’adoption plus solide. Il en irait de même des mises à jour de dépendances en aval, d’exemples communautaires répétés et de rapports de compatibilité provenant de grandes bases de code C.
En attendant leur apparition, ce classement se lit mieux comme un événement de découverte. Il a remis une bibliothèque établie sur le chemin de développeurs parcourant des dépôts actifs.
Cela reste stratégiquement important pour l’open source. Les projets matures rivalisent avec les dépôts plus récents pour l’attention des mainteneurs, les contributeurs, la diversité des tests et la notoriété.
Une brève hausse peut apporter de nouveaux rapports d’incidents et correctifs. Elle peut également attirer des utilisateurs qui attendent du support sans comprendre la capacité du projet.
Les mainteneurs font alors face à un compromis entre l’extension de l’interface et la préservation de la prévisibilité appréciée des utilisateurs établis. fmt 12.2 tente les deux avec de nouvelles surfaces et des correctifs ciblés.
Trois signaux indiqueront si l’attention perdure
Le prochain test n’est pas le classement Trending de demain, mais de savoir si l’attention se transforme en versions publiées, en adoption en aval et en résultats crédibles sur différentes chaînes d’outils.
Le premier signal est fmt 12.2.1. Le journal des modifications du projet étiquette cette version comme à venir et consigne déjà des correctifs et ajouts.
Une publication corrective rapide montrerait que les mainteneurs transforment les retours postérieurs à la 12.2 en un paquet stable. De longs délais renforceraient l’intérêt d’utiliser des commits non publiés ou de maintenir des correctifs locaux.
Le contenu compte autant que le calendrier. Les équipes devraient surveiller si les correctifs répertoriés pour les pipes fermés, le formatage, CMake et les modules arrivent sans introduire de comportement incompatible.
Ce signal renforcerait le récit de maintenance. Il ne prouverait pas que l’apparition dans Trending a directement accru l’activité de développement.
Le deuxième signal est l’adoption de fmt-c. Recherchez les mises à jour de paquets, les dépôts C en aval, les exemples de documentation et les rapports d’incidents fondés sur des déploiements réels.
Quelques démonstrations peuvent valider la syntaxe, mais une utilisation répétée sur plusieurs compilateurs et systèmes d’exploitation testerait la portabilité pratique de l’interface.
La question clé est de savoir si les développeurs C accepteront une nouvelle dépendance pour un formatage orienté types. Les bases de code existantes ont des investissements profonds dans printf, les wrappers et la journalisation spécifique aux plateformes.
Si fmt-c apparaît dans des projets en aval significatifs, l’attention de septembre semblera liée à une véritable expansion. Si l’adoption reste limitée, cela demeurera une expérience notable.
Le troisième signal est l’évolution entre fmt et les fonctionnalités de la bibliothèque standard. Les sorties de compilateurs et les changements de base de référence des projets rendront std::format et std::print accessibles à davantage d’équipes.
Certaines bases de code migreront vers le standard. D’autres conserveront fmt pour les plateformes plus anciennes, des API supplémentaires ou un accès plus rapide aux correctifs.
Les rapports publics de migration peuvent révéler quelles contraintes dominent. Les tests comparatifs devraient inclure le temps de compilation, la taille binaire, le débit de formatage, la portabilité et l’effort de maintenance.
Une vague de migrations vers la bibliothèque standard affaiblirait l’argument en faveur de fmt comme dépendance par défaut. Elle n’effacerait pas son rôle de référence d’implémentation et d’espace de développement.
La poursuite de l’adoption de fmt montrerait que la disponibilité des standards ne règle pas à elle seule les choix d’infrastructure. Le rythme de publication et les environnements pris en charge resteraient déterminants.
Les développeurs qui évaluent fmtlib fmt devraient donc résister à la tentation de transformer la première place en verdict. Commencez par les changements de la 12.2, puis reproduisez les tests pertinents dans votre propre build.
Vérifiez le plus ancien compilateur que vous prenez en charge. Testez les modules uniquement là où la chaîne d’outils complète les prend en charge, et examinez les changements au niveau des correctifs avant de mettre à niveau des systèmes de production.
Pour les projets C, prototypez fmt-c sur de véritables chemins de journalisation ou de diagnostic plutôt que sur des exemples isolés. Mesurez les avertissements, la taille de l’exécutable, le débit et le comportement en cas d’échec.
Le classement de septembre a fourni une invite utile, pas une réponse. Votre prochaine base de référence de chaîne d’outils rendra-t-elle le formatage standard suffisant, ou fmt résout-il encore aujourd’hui un problème de compatibilité concret ?
