Gitversion prend ses aises

Gitversion est un outil ma foi plutôt malin qui regarde un dépôt git et décide du prochain numéro de version, en se basant sur une série de règles, typiquement le tag précédent et certains mots-clé dans les messages de commit. Comme l'outil, ou du moins sa version en ligne de commande (parce qu'il est également disponible en intégration continue par exemple) est plutôt simple, je me suis demandé quelle était la techno derrière.

Un petit ldd plus tard, premier bon point : en fait de dépendances, c'est minimal, en gros libstdc++. Je regarde donc le binaire en lui même, c'est du bon vieux elf, mais les chaines présentes dedans contiennent beaucoup de références à Microsoft. Mhh... Allons donc voir le source.

Et en effet, c'est du C#. Beaucoup de C#, d'ailleurs. Pris d'un doute, je regarde donc la taille du binaire... 66 megs !

Les types ont donc embarqué un interpreteur mono plus tout une palanquée de bibliothèques .NET pour lire quelques lignes de log et générer 3 malheureux nombres qui se battent en duel...

Portabilité, que de disques on a rempli en ton nom !

Question C++ toute bête

Qu'est ce qui est le plus rapide ?

bool a = ...
if (a)
{
  a = false;
}

ou

bool a = ...
a = false;

En gros: est-ce que la lecture est significativement moins chère que l'écriture, et que cela vaut donc le coup de vérifier avant d'écrire la valeur ? Pour l'instant, je l'ignore. M'en vais faire tourner quelques benchmarks pour tenter d'élucider cette question...

Godbolt

Je vous ai déjà dit à quel point ce site était une tuerie ? L'idée de base est géniale : fournir une interface web permettant de tester un programme sur une grande variété de compilateurs, d'en voir l'assembleur généré, et le résultat. Avec une grande quantité de languages (C++, D, Java, Objective-C, Ocaml...) et une grande quantité de compilos (Pour le c++, nous avons pratiquement chaque version de gcc, de llvm, et du compilo de Microsoft, plus tout un tas de variations).

C'est vraiment très, très sympa pour bidouiller, tester une fonctionnalité à venir, vérifier un bug, faire de la micro-optimisation, ou juste partager une idée de code avec quelqu'un d'autre, parce qu'en plus chaque programme est enregistré via un lien unique. Très, très pratique.

125 GB !

J'avais 15 minutes à tuer l'autre soir, et en traînant dans le Gold Pass de la XBox, je me suis dit que c'était l'occasion de tester un jeu de bagnoles. Je vois Forza, je lance l'installation, et je vois que le jeu fait 125 GB. Alors, voyez vous, ça m'a sérieusement refroidi. Parce que bon, même avec une bonne connection, ça fait quand même un bon moment à passer à télércharger toutes ces cochonneries. Serieusement, il y a quoi, là dedans ? Il y a carrément la texture 4K de chaque brin d'herbe et de chaque caillou ?

Alors j'ai laissé tomber, et j'ai plutôt installé un jeu de rallye et un jeu de F1, qui se contentaient de quelques dizaines de GB.

Et puis j'ai découvert qu'en fait je n'aime pas les jeux de voiture.

Addiction à Civilization 6

C'est terrible... À peine sorti de ma 3ème partie de 20 heures, je pense déjà à la prochaine ! Il va falloir que je trouve un moyen de me calmer. Je trouve ce jeu de plus en plus sympa, et en particulier sa variété : un petit peu de city builder, un petit peu de wargame, un petit peu d'exploration... Parfait pour un dilettante comme moi. Venant de remporter une victoire militaire avec les Romains, je tente pour la prochaine la victoire culturelle avec la France sur une carte avec plein d'îles !

C++20 - std::source_location

J'ai eu l'occasion d'expérimenter avec la structure std::source_location, qui est très bien fichue puisqu'elle s'initialise avec les informations courantes de fonction, de fichier source, et de ligne et de colonne dans le source.

Là où c'est très sympa, c'est qu'il est possible en utilisant un paramètre par défaut d'obtenir dans une fonction les informations de l'appelant ! C'est particulièrement pratique, par exemple, pour implémenter une fonction de log qui ne soit pas une immonde macro.

#include <source_location>
#include <iostream>
#include <string>

void log(std::source_location location = 
         std::source_location::current())
{
    std::cout << location.function_name() << std::endl;
}

void f()
{
    log();
}

template<typename T>
void g()
{
    log();
}

int main()
{
    f();
    g<std::string>();
    g<int>();
    return 0;
}

Et voilà le résultat :

void f()
void g() [with T = std::__cxx11::basic_string<char>]
void g() [with T = int]

Là où ça devient intéressant, c'est quand on veut le combiner avec une fonction de log variadique, de type std::format. Puisque l'on ne peut pas mettre le paramètre par défaut à la fin, car c'est ambigu, il faut ruser, et transformer le premier paramètre, typiquement la chaîne de formattage, en un objet spécial qui prend en premier paramètre la chaîne de formattage et en deuxième le paramètre std::source_location par défaut. Puis combiner tout cela avec du consteval et l'empaqueter dans un std::identity_type_t afin qu'il ne participe pas à la résolution des types variadiques, sinon ça ne marche pas !

Je posterai à l'occasion un exemple un peu plus complet. D'ici là, compilez bien.

Un Arduino dans le tiroir

C'est mon côté polarisé qui reprend le dessus - Je viens de ranger les divers composants électroniques de mon Arduino dans des petits casiers, et cela me remplit de joie.

En particulier, je galère moins quand je cherche la bonne résistance. Les anneaux de couleur, c'est sympa, mais à moins de sortir la loupe, je trouve ça tout de même plutôt ardu à déchiffrer.

J'en suis maintenant au montage numéro 6, tout en faisant mes recherches sur la meilleure manière de multiplexer un grand nombre de boutons et d'encodeurs rotatifs. Le hardware, c'est pas facile !