rewind a écrit 3422 commentaires

C'est assez bien résumé :)

Je pourrais entendre cet argument si jamais la page en question n'était pas classé «Satire/Parodie» dans la taxonomie Facebook.

Facebook semble faire pareil en étant assez laxiste sur la modération (complotistes, antivax, etc.).

Laxiste mais pas avec tout le monde… Il y a peu, je me suis fait dégommer un commentaire (mon premier en beaucoup d'années de FB) parce qu'il disait sur un ton humoristique un truc du genre «faudrait tous les envoyer au bûcher». J'ai fait appel, j'ai perdu. Quand je vois aussi que la page satirique «Complots faciles pour briller en société» se fait régulièrement dégager pour des trucs qui relèvent clairement de la satire et de l'humour.

Non, restons sérieux, le laxisme et la liberté d'expression, sur Twitter ou sur FB, c'est toujours pour que les racistes et phobiques de tout poil puissent sortir les pires horreurs sans jamais être inquiétés. D'ailleurs, la liberté d'expression sur Twitter, elle s'arrête (très vite) dès qu'on commence à se moquer du grand chef à plume. Tu parles de la liberté d'expression en carton…

Et on rappellera qu'en France, le racisme n'est pas une opinion mais un délit.

Ce qui a motivé Vulkan, c'est d'une part l'architecture globale d'OpenGL : une machine a états opaque, c'était sans doute bien au début des années 90, ça ne l'est plus du tout aujourd'hui. Et d'autre part les architectures parallèles : faire de l'OpenGL sur plusieurs threads, c'est quasiment impossible, et c'est pas fait pour ça.

Après, l'origine de Vulkan, c'est… Mesa. Et en particulier Gallium3D qui proposait une API très bas niveau pour l'abstraction des cartes graphiques sur laquelle venait se brancher les API haut niveau (OpenGL) via un state tracker. AMD a proposé une API de même niveau et reprenant les mêmes concepts (Mantle) et c'est ce qui a servi de base à Vulkan. Pendant ce temps, MS faisait de même de son côté avec Direct3D 12.

Les shaders sont présents dans OpenGL (et OpenGL ES) depuis plus de 15 ans maintenant je pense (GLSL 1 c'est 2004 dans OpenGL 2).

En fait, ils veulent promouvoir l'utilisation par le commun des mortels de VPN qui permettent de contourner les «protections» mises en place par l'État. Au cas où, dans un «accident démocratique» futur, on se retrouve avec un gouvernement un peu autoritaire… En fait, c'est pour le bien commun !

J'aime bien aussi le système de badge où plus tu participes plus tu as de privilèges (un peu comme sur stackexchange). Une forme de méritocratie légère.

Voilà à quoi est réduite la méritocratie (concept déjà flou au départ) : avoir du temps libre et poster des trucs.

En terme de ray tracing, j'aime beaucoup ce «tutoriel» :
https://raytracing.github.io/books/RayTracingInOneWeekend.html

Il faut faire attention avec char, parce qu'il peut être signé ou non-signé. Et que, c'est là que c'est drôle, il n'est équivalent ni à signed char ni à unsigned char (dans le sens où ce sont trois types différents). Et enfin, ça fout toujours le bazar d'avoir des pointeurs sur char parce que les règles d'aliasing disent que char * peut représenter n'importe quoi, un peu comme void *, et donc ça empêche plein d'optimisations.

À noter qu'il existe depuis C++20 le type char8_t (ainsi que char16_t et char32_t depuis C++11) pour représenter un code unit UTF8 (respectivement UTF16 et UTF32). Je crois que ça va arriver bientôt en C (les deux autres y sont déjà depuis C11).

Je trouve ce commentaire très drôle. Parce que dans la communauté C++, on essaie de mettre de plus en plus de choses dans la bibliothèque standard, et le principal argument de ceux qui freinent cette tendance est de dire qu'il faudrait un bon gestionnaire de dépendances pour qu'on n'ait plus à tout mettre dans la bibliothèque standard.

Ça dépend. Sur ma Debian, j'utilise les paquets de ma Debian. Sur Windows, j'utilise vcpkg. Il m'arrive aussi d'utiliser vcpkg sur Debian quand je veux faire un bon gros binaire statique.

Personnellement, mon principal reproche envers Conan, c'est d'être en Python. J'ai rien contre Python (même si c'est clairement pas mon langage préféré), mais devoir installer une seconde stack logicielle pour pouvoir installer des packages d'une première stack logicielle, je trouve pas ça très optimal pour le coup. Je sais bien que la RAM et les SSD ne sont pas chers de nos jours mais quand même.

Je remarquerai juste que le même genre d'outil, dans les autres langages, est implémenté avec le langage en question. Ça me paraît logique, «eat your own dog food» comme on dit. Même CMake, qui n'est pourtant pas le meilleur outil de build qui puisse exister, il est fait en C++, ils sont donc capable de savoir ce que sont les problèmes dans la construction d'un logiciel en C++ puisqu'ils y sont confrontés tous les jours.

En plus, c'est pas comme si ce genre de logiciel existait déjà, écrit en C++ (apt toussa). Si je devais me lancer dans un projet de gestionnaire de dépendances, je commencerais par forker apt/dpkg et ensuite, j'adapterais pour le cas d'usage visé dans le journal (et attendu par toute une communauté C++) : pouvoir installer un environnement de développement avec plein de dépendances pour le C++.

je refuse catégoriquement d'intégrer Conan à notre base de code C++ juste parce que "les systèmes de dépendances, c'est le futur"

Conan est écrit en Python, c'est pour ça que tu n'aimes pas :) Moi non plus j'aime pas Conan.

Il n'y a pas de pointeur nul !

Si le c++ expose les structures interne, c'est un peu moisi.

It's not a bug, it's a feature! Le fait de n'exposer que des pointeurs force (quasiment) à faire des allocations dans le tas (via malloc typiquement). Exposer les structures internes, ça permet de ne pas faire d'allocation s'il n'y a pas besoin d'en faire. Par exemple, si je fais une classe Vec2 avec deux double: x et y, je n'ai pas envie d'allouer 128 bits à chaque fois que je crée un Vec2, j'ai envie de pouvoir les manipuler directement, sans allocation, de pouvoir faire des additions sans allocation (ce que C++ permet), etc. Et ça, tu ne peux le faire que si tu exposes les structures internes.

Je me suis contenté de relater les drama au sein du comité de normalisation. Et là, c'est bien la question de l'ABI qui a été la goutte d'eau qui a fait déborder le vase de Google. Et quand je dis la question de l'ABI, c'est bien la question de la priorité qui est donné respectivement à la performance et au maintien de l'ABI au sein du comité de normalisation.

Après, c'est juste l'aboutissement d'un long processus où Google n'a clairement pas la main sur sa destinée et c'est bien là le cœur du problème. Créer un nouveau langage est une solution pour eux. Et évidemment, ils ne vont pas faire un langage pourri, ils ont des contraintes industrielles qu'ils sont sans doute les seuls à avoir donc il faut que le langage soit top moumoute sur de nombreux points. Mais ce n'est que la conséquence de tout ce qu'il s'est passé avant. Ce que je veux dire, c'est qu'ils ne se sont pas levé un matin en se disant «tiens si on faisait un nouveau langage !», tout ce qu'il s'est passé ses dernières années dans le comité de normalisation C++ en est à l'origine.

Tu as besoin de changer la représentation pour pouvoir arrêter le thread de manière anticipée. D'ailleurs, je viens d'aller voir dans la libstdc++ et std::jthread est implémenté avec un std::thread et un objet std::stop_source supplémentaire. Si on avait pu changer l'ABI, on aurait mis cet objet directement dans std::thread.

Go n'a pas de problème d'ABI vu que Go compile tout en statique. Les problèmes d'ABI, c'est quand on fait des bibliothèques et que deux morceaux ont besoin de communiquer via un appel de fonction et doivent donc avoir la même représentation binaire des données qu'ils manipulent.

Quant au langage de script, par définition, ils ne produisent pas de binaire (je schématise), donc pas de problèmes d'ABI non plus.

Si si, ils en parlent. Au delà de l'ABI, c'est bien la performance qui est en jeu. La préservation de l'ABI n'est que le symptôme.

Mon préféré dans ce genre, c'est l'événement commercial organisé par nos e-commerce français et qui s'appelle… «Les French Days» ! Quel beau titre pour célébrer la franchouillardise du bidule !

Vu que la population indienne va dépasser la population chinoise sous peu, il va falloir se mettre soit à l'hindi, soit au dialecte anglais pratiqué en Inde.

Vu l'inertie du comité de normalisation, et vu qu'il y a déjà plein de gens en interne qui essaient tant bien que mal de faire pencher la balance du bon côté sans y arriver, je pense que ça ne va pas se passer. Il faudrait une révolution totale du processus de normalisation, en particulier sans doute sortir de l'ISO (avec les risques que ça peut occasionner). Personne n'y est prêt.

La stratégie de Carbon est sans doute la bonne contrairement à tous les C++ killers passés : garder une compatibilité très forte avec C++ en permettant d'utiliser C++ directement dans Carbon. Ça permet une migration incrémentale sans aucun problème.

Côté application, le concept même de DLL/SO est destiné à mourir: on n'a jamais trouvé et on ne trouvera sans doute jamais de bonne solution au dll hell, faire une ABI stable est atrocement difficile…

Je ne dirais pas que c'est difficile. Il y a deux solutions actuellement : la première est celle que tu indiques à savoir tout compiler en statique. La seconde qui est encore beaucoup utilisée est de faire une API C en utilisant au maximum des structures dont l'implémentation est cachée. Avec ça, tu n'as aucun souci vu que l'ABI C est très stable, bien connue, assez simple à comprendre et qu'en prime, ça s'interface avec tous les langages de la Terre.

Même si tu recompiles le monde entier, à un moment tu as quand même besoin de stabilité. D'ailleurs dans le noyau Linux, il y a aussi une garantie d'ABI stable sur certaines interfaces, ce n'est pas pour rien.

Au moment du passage à C++11, GCC a été obligé de changer son implémentation de std::string pour pouvoir être conforme au standard. Ça a été long et douloureux ce petit changement. Notamment dans les distributions, on se retrouvait parfois à ne pas pouvoir compiler un logiciel parce que la bibliothèque qu'on utilisait avait été compilé avec l'ancien version de std::string. Il fallait jongler avec des options du compilateur, c'était pénible. Ça s'est résorbé avec le temps mais je pense que sur certains vieux systèmes où on met à jour la chaîne de compilation, on doit encore trouver ce genre de mésaventure. Et pourtant, ça fait 7 ans. Voir la page du manuel de GCC.

«fausser les choses», tu y vas fort. Pour l'instant, on ne sait pas ce qu'est Carbon vu qu'il n'y a que des documents de design où il est écrit partout «TODO». Donc, je me suis bien gardé d'en dire davantage.

Ils ne promettent pas d'être forcément beaucoup plus safe (notamment pas au niveau de Rust), seulement un petit peu. Ils ne promettent pas d'être plus performant, mais de faire au moins aussi bien que C++. Bref, pour l'instant, il n'y a que des promesses et pas vraiment de concret. Donc attendons de voir. D'après la roadmap, la version 1.0 est prévu pour 2024-2025.

Non, ce n'est pas que de l'API. Si tu changes la représentation interne de ta classe, tu changes l'ABI. Et dans ce cas, tu es obligé, pour gérer la nouvelle fonctionnalité, de changer l'intérieur de ta classe.

Si tu compiles une bibliothèque A avec l'ancien API et une bibliothèque B avec la nouvelle, elles ne pourront pas communiquer avec ce type (au mieux) ou ça va crasher sévèrement (au pire) parce que la représentation aura changé.