rewind a écrit 3422 commentaires

Si le comité prend des décisions qui sont aussi discutables tout en refusant de les remettre en question ensuite, ça ne va pas poser de gros problèmes pour la pérennité du langage d'après toi ? Indépendamment des choix de google.

Oui, ça pose des problèmes et ça en pose de plus en plus. Je vais citer la FAQ de Carbon : «C++'s process is oriented around standardization rather than design». Et je pense qu'ils ont entièrement raison. Pendant longtemps, l'usage, c'était de standardiser les expériences qui marchaient bien. Mais récemment deux exemples ont montré que ce n'est plus le cas.

Premièrement il y a les modules. La proposition au départ était assez simple : se sortir du modèle d'inclusion de texte basique pour aller vers un vrai système de dépendances. L'idée était d'étendre les entêtes précompilés (qui existent depuis des années), les booster un peu et partir sur des bases saines. Avec comme effet de bord que ça pouvait accélérer la compilation. C'était aussi l'occasion de se défaire d'une partie du préprocesseur (but de long terme dans C++ depuis quasiment sa naissance). Il y a eu plusieurs propositions concurrentes (celle de Google et celle de MS), chacune à peu près implémentée (respectivement dans clang et MSVC) mais assez incompatible dans l'idée. Notamment la question du préprocesseur dans tout ça : fallait-il permettre d'exporter des macros ou pas ? ou d'autres questions tout aussi farfelues. Il y a eu d'âpres discussions pour arriver à un consensus et une proposition commune qui reprenaient les pires idées des deux autres propositions. Et au final, on aboutit à une infamie. Parce que personne n'arrive à l'implémenter (MSVC est le plus avancé sur le sujet mais d'après ceux qui l'utilisent, même des exemples simple provoque des crash du compilateur), GCC y travaille mais c'est compliqué, et clang est au point mort. Là, on a eu aucun retour d'expérience avant de standardiser un truc tout bancal. Mais comme le dit Julien Jorge, le comité était sous pression, il avait mis cet objectif dans C++20 donc il fallait que ça sorte dans C++20. Et du coup, ben voilà où on en est, on va sortir C++23 et on ne sait toujours pas utiliser les modules. Parce qu'au delà du compilateur, il faut du support au niveau des outils de build pour que ça fonctionne correctement, et donc (heureusement), ils sont en train de s'entendre pour avoir un format commun d'échange d'information mais c'est pas encore au point. Et puis à la fin, ça n'accélérera pas la compilation puisqu'avec la dépendances entre modules, il faut maintenant compiler les trucs les uns après les autres (ça revient à dérouler un DAG), alors qu'avec des fichiers source des des entêtes, on peut tout compiler en parallèle sans problème (make -j10). Bref, un crash industriel qui finira sans doute dans l'oubli.

Deuxième exemple, le réseau. Moi, contrairement à Julien Jorge, je suis pour qu'il y ait plein de choses dans la bibliothèque standard. Mais en particulier, j'aimerais qu'il y ait plus de choses pour l'abstraction du système. Depuis C++11, on a eu la gestion du système de fichier (std::filesystem), la gestion des threads, la gestion des horloges. On va bientôt avoir la gestion des dates. Bref, tout ça pour moi, ça va dans le bon sens, c'est-à-dire qu'il n'y a rien de bien nouveau là dedans, c'est juste avoir une jolie interface commune à tous les systèmes. Mais il manque des morceaux et notamment le réseau. Or, en matière de réseau en C++, il y a une bibliothèque qui écrase le marché, c'est ASIO (qui est aussi présente dans Boost). Des milliers d'utilisateurs dans tout un tas de contexte, des années de maturation. Le candidat idéal pour une standardisation ! Et bien non, ça n'aura pas lieu. Pourquoi ? Parce que certains huluberlus trouvaient que le modèle de concurrence d'ASIO n'était pas top moumoute. Certains ont proposé de standardiser uniquement les trucs de bases genre socket pour TCP et UDP, résolution de nom, et basta. Mais non, le comité ne voulait pas parce que vous comprenez ma bonne dame, de nos jours toutes les applications réseaux ont besoin d'être parallèle pour gérer des millions de connexions à la secondes et qu'en plus, on veut du SSL par défaut. Donc, on a mis ASIO en attente pour gérer ce qui s'appelle «Executor» et qui est en fait l'introduction d'un modèle de concurrence. Sauf que là, pour le coup, je pense que ça n'a rien à foutre dans la bibliothèque standard un modèle de concurrence. Mais en prime, ils ont trouvé le moyen d'inventer un nouveau modèle (plutôt que de standardiser des trucs déjà existant), à peine testé, et surtout largement incompatible avec la manière dont ASIO fonctionne. Encore un crash industriel en perspective.

On pourrait aussi parler d'une tentative d'introduire une partie audio. Le gars qui a fait la proposition disait en substance : «bon, toutes les API de base se ressemblent, ça consiste à envoyer des données régulièrement à un périphérique audio, il n'y a aucune innovation de ce côté donc on pourrait standardiser ça» (l'équivalent de l'API audio dans la SDL de base typiquement). Sauf que derrière, des spécialistes sont arrivés, ont flingué le truc en disant que ça ne gérait pas le temps réel, et bla bla. Fin de la discussion.

Donc, on va continuer à réinventer des couches d'abstractions pour l'audio et le réseau parce que le comité ne se soucie pas de design d'API simple et efficace qui pourrait servir à 95% des gens mais se soucie de normaliser des trucs, peu importe ce que c'est. std::thread c'est pas fait pour ceux qui font du parallélisme de pointe (genre HPC) qui auront leurs propres solutions, mais on s'en fout parce que les 95% d'usages restant sont couverts. De même, std::vector, c'est un tableau dynamique de base qui sert 95% des usages, mais dans le jeu vidéo AAA où ils ont besoin d'avoir une maîtrise très fine (et aussi un peu de NIH), ils réimplémentent les tableaux dynamiques. De nos jours, le comité souhaitent que les trucs standardisés puissent être utilisé par les spécialistes et donc on monte des usines à gaz et au final, on se retrouve avec de la merde que personne ne peut utiliser parce que c'est trop compliqué (coucou les coroutines).

Donc pour revenir à la question, oui ça pose problème à force. Parce que le problème orthogonal, c'est qu'on n'a pas de bon gestionnaire de paquets pour C++ (à l'instar d'un cargo pour Rust par exemple, et on pourrait d'ailleurs citer tous les autres langages en exemple), et donc on est encore condamné à bricoler suivant les systèmes (gestionnaire de paquets de la distrib dans Linux, avec les limites que ça peut avoir / vcpkg sous Windows) si on veut pouvoir tirer des fonctionnalités de base de bibliothèques externes à la bibliothèque standard.

Personnellement, je suis resté à C++17, parce que c'était la fin du cycle commencé en C++11 et que c'est suffisamment mature. Pour la suite, j'attends de voir ce qu'il va se passer, que ce soit du côté de C++ ou du côté de Carbon. Rendez-vous dans quelques années.

Cette histoire d'ABI, ça gonfle tout le monde. Par exemple, en C++20, il y a std::jthread qui apporte la possibilité d'arrêter le thread. Normalement, ça aurait dû être intégré dans std::thread mais comme on ne pète pas l'ABI, on a maintenant 2 types pour les threads.

Et puis il y a aussi des problèmes plus profond. Par exemple, passer un std::unique_ptr en paramètre ne permet pas de le passer dans un registre alors que par défaut, un std::unique_ptr, c'est juste un pointeur dans une structure et que ça pourrait être passé via un registre.

À la fin, ça fait plein de petits trucs qui font que Google en a eu marre. En particulier, ils ont proposé de mettre la performance en tête des priorité du comité de normalisation C++, ils ont été mis en minorité. Et puis il y a eu les propositions sur les modules, ils avaient fait une proposition très pragmatique, mais Microsoft a fait un peu du forcing et il y a eu conciliation qui a abouti à une horreur (d'ailleurs pas encore implémenté ni dans GCC, ni dans clang).

Je pense qu'au delà des questions de performances, il y a surtout des questions d'orientation de C++ qui échappent totalement à Google, parce que l'ISO, c'est compliqué et que le comité C++ de l'ISO, c'est encore plus compliqué. Google a essayé d'influer autant que possible mais ça n'a pas bien marché. Et vu les enjeux financiers, ils ont intérêt à faire un truc de leur côté, ils en ont les moyens et sur le long terme, c'est gagnant pour eux.

Je t'invite à écouter ces quelques minutes de Frédéric Lordon qui vont peut-être transformer ton éco-anxiété : https://www.youtube.com/watch?v=CrKmxPkV2jY

ℝ n’est pas défini à partir de ℚ

Si, ℝ est défini traditionnellement comme étant l'ensemble des limites des suites de Cauchy dans ℚ.

Je suis déçu, je pensais qu'on allait voir une grammaire du langage. Mais non, pas encore. Mais ça serait bien de définir une grammaire (ou du moins des morceaux de grammaires) pour qu'on se fasse une idée plus précise du langage autrement qu'avec des exemples. Une spécification, ça doit être assez formel et les grammaires sont le bon outil pour un langage (même si ça ne suffit).

démocratie + européanisme + économie + social + libéralisme + écologie

la carpe + le lapin + le beurre + la crémière + tout, son contraire, et même l'inverse

Il y a de l'espoir, et on peut aussi se dire qu'en France on a perdu une occasion de faire pareil…

Personnellement, j'appelle pas ça un espoir, mais un cauchemar !

Pourquoi ASan avec GCC et MSan avec Clang ? Les deux outils (ASan et MSan) ne visent pas du tout les mêmes types d'erreurs (et il me semble même qu'on peut les combiner). Il aurait fallu voir les deux outils avec les deux compilateurs (même si je pense que ça ne change pas grand chose, mais c'est mieux de le vérifier).

Le cas des élèves est très simple : ils n'ont pas de droit sur les logiciels réalisés dans le cadre de leurs études. En fait, dans ce cas, on considère que ce qu'ils ont réalisé n'est pas venu de leur cerveau mais a été demandé par un supérieur (un prof) et qu'ils ont été encadré pour le faire, donc aucune inventivité propre.

En revanche, dès qu'ils sont en stage, c'est tout le contraire, ils ont tous les droits sur ce qu'ils produisent dans l'entreprise. À moins que la convention de stage ne précise que les droits sont cédés à l'entreprise. Mais par défaut, ils gardent les droits.

Boost n'a jamais prétendu être une bibliothèque header-only. Il n'y a pas que system qui a besoin d'une bibliothèque compilé (il y a aussi program_options, filesystem, regex, locale, serialization et sans doute d'autres).

Ensuite, si, c'est modulaire, justement. Mais le problème vient du fait qu'il y a beaucoup de dépendances entre ces modules. En cherchant, on trouve sur le net le graphe de dépendances et c'est juste un enfer, ce qui fait que quand on tire une des bibliothèque de haut niveau, on tire la moitié des autres (mais après, c'est ce que promeut Moonz avec les crates de Rust).

Chacun des deux systèmes (ultra-modulaire, ou largement monolithique) a ses avantages et ses inconvénients. Vu npm ou les crates ou boost, je ne suis pas sûr de vraiment préférer le système ultra-modulaire.

Et paradoxalement, la plupart des langages avec des spécifications libres n'ont qu'une seule implémentation, là où C et C++ en ont des dizaines.

Concernant C++, la spécification finale n'est pas libre, mais la version bêta juste avant la spécification finale est disponible. Par exemple, pour C++20

Autant tout recopier, c'est assez instructif :

• Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring.
• Rust needs to demonstrate that it can be used to create general-purpose libraries that are callable from all other programming languages.
• Rust needs to demonstrate that it can produce object code that works on obscure embedded devices, including devices that lack an operating system.
• Rust needs to pick up the necessary tooling that enables one to do 100% branch coverage testing of the compiled binaries.
• Rust needs a mechanism to recover gracefully from OOM errors.
• Rust needs to demonstrate that it can do the kinds of work that C does in SQLite without a significant speed penalty.

C'est vrai que boost, c'est un gros truc monolithique, c'est d'ailleurs bien ce qu'on lui reproche… oh wait!

Pour une certaine définition de «taille», ça marche. Après, si on va sur Unicode, on a (au moins) quatre autre définitions de «taille», on prend laquelle ?

Moi, un étudiant me rend un code comme ça, je le pends par les pieds. Parce que là, ça ne demande qu'à péter à la gueule de celui qui va l'utiliser.

Il suffit de faire une copie du texture_manager et là, je vais avoir des doubles appels à DestroyTexture, ça va être très fun. Et le problème vient du fait qu'à la base, on peut copier le defer_frame alors que ça n'a aucun sens.

Moi, je suis comme devnewton, je suis partisan du RAII, c'est pas fait pour les chiens et au moins, c'est safe.

Et que COBOL !

Eux-même n'étaient pas antivax, ils se pensaient juste dans une condition physique suffisamment bonne pour pouvoir résister à la maladie. Mais à 72 ans, ils n'ont plus un système immunitaire aussi performant. Ce qui les a tué, c'est leur égo.

PS. J'ai franchement aimé aussi, mais je déteste cet ajout "francophone" au titre anglophone : "déni cosmique". Si le titre anglais "don't look up" n'étais pas assez clair, traduisez-le !

Si je ne dis pas de bêtise, ça a à voir avec la loi française qui veut qu'on mette des titres français, mais qui autorise les titres étrangers s'il y a une «traduction» du titre étranger.

Après une petite recherche, j'ai trouvé ça : https://www.csa.fr/Proteger/Medias-audiovisuels-et-Francophonie/Anglicismes-les-equivalents-francais-recommandes

Je n'ai vu nulle part dans la dépêche une justification du changement de version majeure. Il y en a une ?

Du coup, l'idée de ne sauver que le code pur (une version minifiée), et laisser tout un chacun d'afficher de jolies tabulations sur 2 espace ⅓ si ça le chante, oui j'aime bien.

Si c'est vraiment minifié, tu retrouves tout ton fichier sur une seule ligne et du coup.

Error line 1: bla bla

Ça devient beaucoup moins simple d'identifier où se trouve l'erreur. Le format texte a ça de bien qu'on peut en faire ce qu'on veut et on peut même faire des dessins avec les caractères. Il est tellement simple que tout logiciel ou tout langage peut le manger tel quel et faire ce qu'il veut avec. C'est sa force. Et donc, supprimer sa force et devoir passer par des outils tiers (complexe) pour modifier ou lire un code source, bof bof comme idée. Actuellement, je peux lire un code source avec more (et oui, ça m'arrive très souvent), si tout est sur une seule ligne, je fais comment ?

Indice: https://fr.wikipedia.org/wiki/Amazon_Game_Studios

Le moteur n'est pas un produit à vendre pour eux, donc le mettre open source est un moyen de le populariser et qu'il soit utilisé (et même que la communauté le maintienne un peu et corrige les bugs). C'est un avantage concurrentiel par rapport aux mastodontes du secteur (Unreal, Unity).

Sous Windows, le choix a été fait de ne reposer que sur clang-cl pour l'étape de compilation finale, MSVC et le C++ moderne, ça reste une source de déception sans fin pour moi, j'ai remonté plusieurs bugs puis juste abandonné l'idée…

Ça s'améliore mais vraiment à une allure de sénateur. Et puis là, ils sont en mode «on ajoute des fonctionnalités» plutôt que de refaire la base (c'est-à-dire avoir un AST qui leur permette de gérer enfin les templates correctement). Et ils galèrent (comme les GCC et clang) sur C++20 qui est un très gros morceau.

Même si c'est standard, j'en mets toujours un. Et je fais même pire.

#include <cstdlib>

int main() {
  return EXIT_SUCCESS; // or EXIT_FAILURE
}

Allez, tu as pris les devants dans ton journal mais je vais quand même le dire. C'est dommage que ce soit en anglais. Il existe déjà pas mal de documentation en anglais sur C++, tu ne pourras pas rivaliser en tant que locuteur non-natif de ce dialecte. Alors que la documentation en français sur C++ est quasi-inexistante. Je vais même aller plus loin, j'aurais bien contribué si ça avait été en français, parce que je me dis qu'un tel document aurait sans doute été très utile à mes étudiants. Bref, c'est ton choix, ce n'est pas très grave, ça fera toujours quelque chose en plus à se mettre sous la dent.

J'ai commencé à parcourir, ça a l'air plutôt bien rédigé. J'ai juste quelques remarques pour l'instant.

Dans la section 2.4.1, tu fais une classe avec des attributs const. C'est une très mauvaise idée parce qu'une telle classe sera difficilement utilisable en pratique parce que tu ne pourras plus utiliser le déplacement (move) du fait du const. Avec des types simples, ça ne se verra pas, mais dès que tu vas utiliser std::string par exemple, ton déplacement va se transformer en copie et donc, va potentiellement envoyer une exception et donc tout va te coûter plus cher parce qu'il y a tout un tas d'optimisations liées au fait qu'un déplacement ne peut pas envoyer d'exception (noexcept), comme dans std::vector par exemple. Du coup, pour illustrer ton chapitre, je prendrais plutôt une référence comme attribut, parce que déjà tu ne peux plus faire de init comme tu le fais là, et que du coup, les constructeurs délégués prennent tout leur sens.

Dans la section 2.4.5, tu utilises des identifiants avec deux underscores consécutifs. Normalement, tu n'as pas le droit, tous les identifiants avec deux underscores consécutifs sont réservés.

Dans la section 2.5.9, je pense que std::bind a plus ou moins été supplanté par les lambdas. Dans plein de cas, tu peux créer une lambda qui fera exactement pareil et qui sera sans doute plus simple une fois compilée que tout l'attirail derrière std::bind dont tu donnes un aperçu dans la section précédente.

Dans la section 2.6.5, il y a une typo, il manque un underscore devant g dans la définition.

Ça fait un moment qu'on peut créer des transitions douces, il suffisait d'annoter les tilesets avec des informations de terrain et la brosse «Terrain» permettait de dessiner des terrains et Tiled comblait utilement les trous. D'ailleurs, quand la fonctionnalité des wangset a été ajoutée, je me suis demandé à quoi ça servait par rapport aux annotations de terrain, et j'ai ma réponse dans le changelog de la version 1.5 : ça ne sert à rien. En effet, les deux fonctionnalités ont été fusionnées en interne, même si les deux restent dans le format.

Ceci dit, ça reste un excellent logiciel, je suis entièrement d'accord avec ce point, et je l'utilise également pour mes jeux. J'ai même fait un générateur de tileset qui, à partir d'un certain nombre de terrains et d'informations concernant les associations à faire entre terrains, est capable de générer les tilesets TMX et l'image qui va bien, avec toutes les annotations de terrain pour pouvoir éditer des cartes facilement par la suite. Et j'ai même mis des propriétés de collision pour pouvoir calculer automatiquement toutes les formes de collisions sur la carte. Je ferai peut-être un journal un jour…

Tu as raison, la sécurité d'abord !

C'est pas une question de sécurité, c'est une question de bénéfices/risques. Avec un tel dispositif, il y a un grand bénéfice, et assez peu de risque. Donc, je prend. Après, si vraiment on ne veut pas être traqué, on peut ne pas avoir de téléphone.