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.
[^] # Re: C'est moi ou c'est idiot ?
Posté par rewind (Mastodon) . En réponse au journal Google forke C++. Évalué à 10.
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::threadc'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.