Julien Jorge a écrit 526 commentaires

Si je peux changer ma représentation interne d'une classe, ne pas recompiler ceux qui utilisent cette classe et tout de même linker avec c'est qu'il n'y a pas de problème d'abi ?

Ça ne suffit même pas :) Regardez par exemple cette belle lib que l'on va générer en deux versions :

// lib.hpp
#pragma once

struct something
{
  void print() const;
  int a;
};

// lib.cpp
#include <lib.hpp>

#include <cstdio>

void something::print() const
{
  printf("v1 %d, sizeof(*this)=%lu\n", a, sizeof(*this));
}

On compile cela et on envoie le .so au client :

$ g++ -shared -fPIC -I. lib.cpp -o liblib.so

De son côté le client écrit ce programme :

// client.cpp
#include <lib.hpp>

#include <cstdio>

int main()
{
  int a = 32;
  something s{64};
  int b = 128;

  s.print();
  printf("sizeof(s)=%lu\n", sizeof(s));

  return 0;
}

Il compile ça et teste :

$ g++ -I. client.cpp -o client -Wl,-rpath,'$$ORIGIN' -L. -llib
$ ./client
v1 64, sizeof(*this)=4
sizeof(s)=4

Tout va pour le mieux.

Le vendeur de lib fournit maintenant une nouvelle version de sa lib, la version 2, avec deux fois plus de champs dans something.

// lib.hpp
#pragma once

struct something
{
  void print() const;
  int a;
  int b;
};

// lib.cpp
#include <lib.hpp>

#include <cstdio>

void something::print() const
{
  printf("v2 %d, %d, sizeof(*this)=%lu\n", a, b, sizeof(*this));
}

Compilé de la même façon, il envoie le .so au client qui remplace directement l'ancien fichier et relance son programme :

$ ./client
v2 64, 32, sizeof(*this)=8
sizeof(s)=4

Et voilà, le programme se lance bien, il affiche n'importe quoi (la lib voit dans something::b la valeur 32 qui est dans la pile côté client) et on voit que le client et la lib ne sont pas d'accord sur la taille de something.

La mise à jour de la lib n'est pas ABI compatible avec la version précédente et pourtant ça link bien. Sur cet exemple c'est bénin mais en pratique ça cause de sacrés problèmes. Et il ne suffit pas d'ajouter ou supprimer des champs pour causer des soucis, rien que changer l'ordre pose problème.

Le comité subit une sorte de pression pour mettre tout un tas de trucs dans la lib standard parce que tel autre langage a telle possibilité ou parce que tel truc est tendance. Du coup ils ont des propositions pour mettre du networking, une api de dessin 2D (abandonnée), des bases de données (abandonnée aussi il me semble), des ranges (i.e. de la composition d'algos) et 2000 autres trucs parce que Java/Python/Autre langage le fait. Ça devient très, très, très complexe.

À côté de cela on leur demande de livrer un nouveau standard tous les 3 ans parce qu'on a attendu c++0x trop longtemps et qu'on ne veut par subir ça à nouveau. Et puis on aimerait bien être moderne, comme tel autre langage jeune, beau, et tellement cool.

Du coup ils se retrouvent coincés entre livrer un truc bien pensé ou livrer pour qu'on leur lâche la jambe. Le résultat n'est pas toujours heureux.

À cela s'ajoute le fait qu'il s'agit de logiciel et donc fatalement toute décision est une mauvaise décision après un laps de temps suffisamment long.

Personnellement je pense que la lib standard doit être good enough comme on dit, justement parce qu'il n'y aura jamais une implémentation qui satisfait tout le monde. Si on veut aller dans le détail on a toujours la possibilité de prendre une lib à part.

Après pour ce qui est de l'ABI, est-ce vraiment une mauvaise chose que de vouloir éviter de casser l'existant ? Je n'ai pas trop d'avis là dessus.

L'auteur m'a l'air bien agressif pour pas grand chose. Voici les deux paragraphes qui portent l'information :

A few weeks ago, Microsoft quietly updated its Microsoft [app] Store Policies, adding new policies (which go into effect next week), that include this text:

all pricing … must … [n]ot attempt to profit from open-source or other software that is otherwise generally available for free [meaning, in price, not freedom].

Microsoft [argues] that this is about curating content for customers and/or limiting FOSS selling to the (mythical) “One True Developer”. But, even a redrafted policy (that Giorgio Sardo (General Manager of Apps at Microsoft) hinted at publicly early today) will mandate only toxic business models for FOSS (such as demo-ware, less-featureful versions available as FOSS, while the full-featured proprietary version is available for a charge).

Ce que je comprends c'est qu'il y a une nouvelle règle pour ne pas abuser du travail fait par les développeurs de logiciels libres.

Perso je ne vois pas trop la gêne, je suis sûrement influencé par l'opinion d'un grand logiciel libre sur cet excellent site il y a quelques jours :

D'ailleurs en parlant d'utiliser le nom, il y a aussi la problématique de se faire des sous faciles en induisant en erreur les acheteurs. Beaucoup croyaient aider le développement du projet GIMP en payant sur la boutique en ligne. Ce n'était pas forcément une usurpation d'identité claire […], mais beaucoup laissaient simplement un flou suffisant en n'annonçant pas explicitement être un empaqueteur tiers tout en mettant un prix […]. Ce n'était pas agréable que des gens aient ainsi la sensation de se faire arnaquer en utilisant la réputation de notre logiciel.
[…]
Malheureusement force est de constater que des empaqueteurs se contentaient de reprendre notre travail et de le faire payer en gardant le flou sur la provenance. Certes pas illégal, mais un business bien tristounet.

C'est corrigé :) Merci po,ur le journals.

Je connais pas la raison de l'impossibilité d'éditer son journal mais j'ai quand même corrigé le lien :)

Le journal suggère quand même que la cause de l'arrêt d'Atom est le rachat par Microsoft, et que l'arrêt est fait dans le but de favoriser VS Code. Alors certes ce n'est pas « méchant Microsoft » mais ce n'est ni neutre, ni « gentil microsoft » :)

Avec les écrans qu'on a aujourd'hui il n'y a pas de raison de se limiter à 400 lignes. Moi avec mon 50 pouces installé en portrait, je mets une police 6 et je peux afficher 73269 lignes sans problème.

Je comprends ta souffrance et pourtant ça ne me semble pas évident. Quand je repars sur des trucs simples, j'en reviens toujours à ressentir les mêmes effets :

• trop de lignes dans le fichier : « c'est le bordel, ce fichier fait trop de trucs »
• trop de trucs enfouis dans le bazar : « pas moyen d'écrire un test unitaire pour cette fonction déclarée statique au fond d'un fichier avec dépendances à des variables globales » (ça marche aussi avec trop d'encapsulation)
• au bout d'un moment j'en ai marre et je range : « et vas-y qu'il faut que je déplace tout le bazar, et vas-y qu'il y a des dépendances implicites et des raccourcis moisis ».

Alors avec le temps je préfère encore une arborescence plutôt vide qu'un petit tas de trucs empilés en vrac :) La simplicité, je la cherche ailleurs : calmos sur l'OOP, calmos sur la metaprog, calmos sur les dépendances third party (outillage ou libs).

Pour le multi-dépôts je n'ai pas encore tranché. J'aime que ce soit séparé et isolé, mais d'un autre côté le mono-repo est bien confortable pour les refactos et pour retrouver tout le projet dans un état donné.

Au boulot on utilise la stratégie que tu décris. Nous avons environ 30 000 lignes d'assembleur (en utilisant des intrinsèques, ce qui est quand même plus pratique que l'assembleur brut) et la principale motivation est d'avoir ces fonctions aussi optimisées que possible. Le meilleur moyen d'y arriver est de les écrire avec les instructions que nous voulons voir dans le binaire. Le cadre est assez fixe cela dit puisque nous visons un seul couple architecture/compilateur.

Nous avons aussi une version C pour chaque fonction optimisée, à la fois comme fallback mais aussi comme référence pour la version assembleur.

En pratique on remarque que certains compilateurs arrivent à émettre de l'assembleur équivalent à celui écrit à la main depuis fonctions C. Ce n'était pas le cas avec de plus anciennes versions.

Perso je trouve qu'il nous manque quelque chose pour mesurer le gain apporté par les fonctions optimisées, pour voir si elles sont toujours pertinentes. Nous avons des mesures globales, qui englobent toutes les optims, mais rien individuellement. J'ai bien entamé un truc à base de Google Benchmark mais ce n'est pas évident d'avoir un test représentatif des cas d'utilisation réels.

Je l'utilise le plus souvent pour confirmer que le compilateur va bien effectuer certaines optims (genre éviter d'appeler systématiquement une fonction dans une boucle quand son résultat ne dépend pas de l'itération).

Le deuxième cas d'utilisation que j'ai est de comparer les sorties de différents compilateurs.

Et de temps en temps c'est aussi juste pour être impressionné par les transformations d'optimisation.

C'est corrigé, merci :)

Que ce soit pour les liens ou les journaux notre politique est de ne pas filtrer et de laisser faire le moinsage. Il y a régulièrement des contenus qui ne concernent ni le libre ni l'informatique et qui sont pourtant bien accueillis, et si nous commençons à les bloquer en amont nous allons nous priver de contenus intéressants ou divertissants, y compris de ce putain d'ornithorynque.

C'est une situation de tout ou rien. Du coup la seule solution valable est de ne bloquer que ce qui est manifestement illégal. La communauté se charge d'évaluer l'intérêt du reste. Dans les faits on observe que ça reste grosso-modo dans le thème.

Merci, c'est important pour ma street cred' :)

Comme tu as l'air nouveau sur le site je me permets de te pointer un journal que j'avais écrit sur le sujet ;)

Aussi disponible en français sur LinuxFr.org ;)

C'est fait :)

ça veut dire qu'il fonctionne sur un binaire dont on a pas les sources?

Tout à fait, Valgrind et Inspector peuvent trouver des erreurs sans des binaires sans avoir les sources. Par contre s'il n'y a pas les symboles de debug ils vont avoir du mal à dire de quelle ligne ça vient. De tête il me semble qu'ils affichent l'adresse de la fonction.

Bien vu ! Merci :)

Ceci dit, je me suis déjà compilé des versions récentes de clang++ pour CentOS. C'est fort pratique pour avoir des outils tels que les sanitizers, de meilleurs warnings, clang-tidy, un serveur LSP, etc même quand on est restreints à du C++ 98.

Si tu as des conseils pour avoir un Clang 13 ou ultérieur sur CentOS 7.9 ça m'intéresse. De souvenir je n'avais pas pu le compiler car le compilateur installé, GCC 4.8 ne supportait pas une version suffisamment récente de C++.

Pour la machine dans le nuage j'ai gardé le GCC de base car c'était notre second compilateur de référence. Comme c'est un vieil OS avec de vieux outils je n'avais pas de quoi y tester MSan avec Clang. Pour ma machine locale j'ai gardé GCC pour ASan afin de pouvoir comparer les résultats d'une simple mise à jour de compilateur.

Dans l'absolu j'imagine que le compilateur ne joue pas tellement sur les résultats d'ASan puisque c'est une lib développée indépendamment.

C'est fait. J'ai remplacé une paire de « and » par « et » aussi.

Merci pour le journal, c'est très intéressant :)

L'idée est de partir de la base existante de pcmemtest tout en gardant le nom originel, puis d'y ajouter du code issu des développeurs de Memtest86+.

Vu que pcmemtest est en GPL 2, a priori ça sera libre.

Si on pouvait supprimer cela ainsi que toute forme d'assistance dans les formulaire texte, ça m'irait très bien :

• les popups d'emoji de GitLab.
• le remplacement automatique des smileys ascii par des images, en particulier la substitution d'un simple sourire :) par un emoji aux yeux écarquillés et au sourire jusqu'aux oreilles. Si je voulais une image, j'insérerais une image.
• les popups Azure de liens vers d'autres tickets lors de l'appui sur #. C'est en particulier l'horreur dans le wiki Azure, où # sert aussi à écrire un titre, du coup à chaque saisie d'un titre une popup sans rapport apparaît.
• le fait que lorsque je sélectionne du texte pour le remplacer par du code inline dans un commentaire sur GitLab ou sur Slack, je tape ` et le texte sélectionné devient du code inline au lieu d'être remplacé comme dans tous les éditeurs textes depuis toujours.
• les doubles quotes de fin de chaîne caractères qui s'ajoutent toutes seules quand je commence une chaîne sur Compiler Explorer et dans la plupart des IDEs, idem pour les accolades et les parenthèses. (Je sais fermer une parenthèse, merci

En fait toute forme d'action non sollicitée dans une zone de texte.

N'étant pas une personne active sur les réseaux sociaux, depuis le début de la campagne je cherche à atteindre les bonnes communautés (anglophones surtout) et ce n'est pas évident, j'aurais peut-être dû mettre un durée de campagne de 60 jours, je pensais Kickstarter plus "efficace" à amener du monde, en vendre 250 ne me semblait pas un chiffre démesuré :-)

Une campagne de financement participatif c'est avant tout un travail de relations publiques. Personne ne tombera sur le projet par hasard et il y a très peu de chances que Kickstarter te mette en avant. Du coup c'est essentiel de communiquer très fréquemment sur ton projet, sur toutes les étapes. En plus des forums ça vaut le coup de contacter aussi des journalistes de sites de matériel ou des youtubers du domaine, et transmettre au gens que c'est un sacrément chouette clavier. Idéalement il aurait même fallu faire la communication dès la genèse du projet, bien avant de lancer la campagne de financement :)

C'est bien mais le premier truc que je relèverai est que les std::function vont faire des allocations dynamiques, de même pour le std::vector.

Exercices pour le lecteur, et l'auteur :

1. dans quels cas std::function ne fera-t-elle pas d'allocation dynamique ? Est-ce garanti ?
2. proposer une implémentation qui ne fait jamais d'allocations dynamiques.

Et sur un autre sujet, tu ne devrais pas utiliser __ pour tes variables, c'est réservé pour le compilateur :)

C'est corrigé :)