C++ 20 est publié avec de nouvelles fonctionnalités pour le langage et la bibliothèque

La conception de C++ 20 est achevée et le premier brouillon sera publié en juillet 2019,
les Modules et les Coroutines y sont présents

La toute dernière réunion du comité ISO C++ pour approuver les nouvelles fonctionnalités à venir dans C++ 20 s’est tenu la semaine passée à Kona, à Hawaii. À l’issu de cette réunion, le comité a annoncé que les fonctionnalités du prochain standard international (SI) du langage de programmation C++, le C++ 20 sont maintenant finalisées. Il a également indiqué qu’une prochaine réunion, prévue pour juillet prochain, mettra fin à la spécification et verra la publication d’un brouillon pour examen. Le président du comité de normalisation ISO C++, Herb Sutter, (également auteur, conférencier et architecte logiciel chez Microsoft) a déclaré ce qui suit : « Nous connaissons ainsi la plupart des fonctionnalités finales de C++ 20 ! Lors de notre prochaine réunion en juillet, nous prévoyons d’adopter officiellement quelques fonctionnalités supplémentaires qui ont été approuvées par la conception lors de cette réunion, mais qui n’ont pas encore été révisées dans leur intégralité. À la fin de la réunion de juillet, nous lancerons ensuite le premier bulletin de commentaires pour C++ 20 pour d’examen ».

Parmi les nombreuses nouvelles fonctionnalités approuvées pour le C++ 20, deux fonctionnalités majeures sont à noter. Il s’agit des fonctionnalités dénommées Modules et celles dénommées Coroutines. Comme l’explique Herb Sutter, les Modules constituent une nouvelle alternative aux fichiers d’en-tête et apportent un certain nombre d’améliorations clés notamment en isolant les effets des macros et en permettant des générations évolutives. Cette fonctionnalité permet aux utilisateurs du langage de définir une limite d’encapsulation nommée, une première depuis ses 35 ans d’âge selon Sutter. Il existait jusque-là trois fonctionnalités de ce type qui permettent aux programmeurs de créer leurs propres mots de pouvoir en (a) donnant un nom défini par l'utilisateur en (b) quelque chose dont l'implémentation est cachée, explique Sutter. Ce sont : la variable (qui encapsule la valeur actuelle), la fonction (qui encapsule le code et le comportement) et la classe (qui encapsule les deux pour délivrer un ensemble d’états et de fonctions).

Même des fonctionnalités majeures telles que les Modèles constituent des moyens de décorer ou de paramétrer ces trois fonctionnalités fondamentales. À ces trois, est ajoutée maintenant une quatrième, les Modules qui encapsulent les trois pour en livrer un ensemble. Les Coroutines quant à eux, sont des fonctions qui peuvent suspendre et reprendre leur exécution tout en conservant leur état. L'évolution en C++ 20 va encore plus loin. Le terme Coroutines est inventé par Melvin Conway, un informaticien. Il l'a utilisé dans sa publication pour la construction d'un compilateur en 1963. Cette fonctionnalité existe également dans les langages comme Python. L'implémentation spécifique de Coroutines en C++ est un peu intéressant. Au niveau le plus élémentaire, il ajoute quelques mots-clés à C++ comme co_return, co_await, co_yield ainsi que des types de bibliothèques qui fonctionnent avec eux. Une fonction devient une coroutine en ayant une de ces fonctions dans son corps.

Pièce jointe 453086

Lorsqu'un de ces trois mots-clés est utilisé dans un corps de fonction, un examen standard obligatoire du type de retour et des arguments est produit et la fonction est transformée en une coroutine. Cet examen indique au compilateur où stocker l'état de la fonction lorsque celle-ci est suspendue. La spécification s’est portée également sur d’autres fonctionnalités et modifications telles que :

• l’extension des liaisons structurées et la capture de référence des liaisons structurées qui permettent à un nom introduit en tant que liaison structurée d'être utilisé de manière supplémentaire, par exemple d’être capturé par référence dans des lambdas ;
• ⇔! === qui ajoute une meilleure prise en charge linguistique pour la composabilité lors de l'écriture <=> pour les types pouvant écrire un == plus efficace que d'utiliser l'opérateur <=> seul. Par exemple, le vecteur <T> peut court-circuiter la comparaison == en vérifiant d’abord si les deux vecteurs ont la même taille ;
• changer span pour utiliser une taille non signée et ajouter des fonctions ssize() pour obtenir les tailles signées. Cette fonctionnalité rend std::span plus pratique à utiliser avec les types STL existants, tout en permettant l’utilisation de tailles et d’index signés via ssize( ) pour bénéficier des avantages de la signature ;
• le polymorphic allocator. Il permet à pmr::memory_resource d'être utilisée partout où des allocateurs peuvent être utilisés dans la bibliothèque standard ;
• etc.

Le comité à travers le reportage de Sutter, a indiqué que les processus tels que les exécuteurs et la mise en réseau continuent de progresser, les deux étant étroitement liés. « Nous espérions qu'une partie des exécuteurs serait prête pour le C++ 20, mais ils n'ont pas réussi la coupe. Ils sont tous deux sur la bonne voie pour bientôt, post C++ 20 (c'est-à-dire au début de la phase C++ 23) », a expliqué Herb Sutter, le président du comité. Beaucoup félicitent l’effort mis en œuvre par le comité pour offrir ces nouvelles fonctionnalités à la communauté C++ et l’encouragent à faire encore plus pour la prochaine standardisation du langage (C++ 23).

Cependant, certains expriment leur mécontentement par rapport au fait que la mise en réseau soit encore laissée de côté comme il a été le cas plusieurs fois déjà. Néanmoins, pour l’effort qui est fait, plusieurs y voient une expérience très excitante et encouragent à une adoption à grande échelle du C++ 20. Les autres fonctionnalités telles que les Concepts, les Ranges, les Contrats qui avaient été introduites dans C++ 20 avant cette réunion sont présentées et expliquées sur le site de l’ISO C++. Vous y retrouverez également d’autres annonces ainsi que le calendrier des autres événements à venir pour livrer complètement le C++ 20.

Source : Billet de blog

Et vous ?

:fleche: Que pensez-vous de ces nouveautés de C++ 20 ?

Voir aussi

:fleche: De C++14 à C++17, qu'est-ce qui a changé avec la nouvelle version du langage C++ : un document de la Standard C++ Foundation

:fleche: La spécification de la nouvelle version du langage C++ (C++17) est finalisée quelles sont les nouveautés introduites ?

:fleche: Le premier brouillon de la prochaine révision du standard C, le C2x, est publié et met l'accent sur la compatibilité du langage

:fleche: Internet aurait de sérieux problèmes à cause de langages comme C et C++ favorisant la survenue de failles mais peu de développeurs s'en soucieraient

C'est une version bien pleine, très intéressante et ça promet du boulot pour maîtriser tout ça. Voilà la liste des nouveautés dans le post de Herb Sutter (en plus il précise "modulo any additional features in July"):

modules
coroutines
concepts
contracts
<=> spaceship
“lots more constexpr”: broad use of normal C++ for direct compile-time programming, without resorting to template metaprogramming (see last trip report)
ranges
calendars and time zones
span
and lots more

Il a raison de dire:

Citation:

---

Envoyé par Herb Sutter

We understand that’s exciting, but we also understand that’s a lot for the community to absorb

---

Enfin les modules !!! :lahola:

C'est pas mal, mais bon le C++ est très en retard est encore très loin de pouvoir rattraper l'énorme avance du C# qui est bien plus moderne et surtout bien mieux foutu, le C++ reste un langage désuet et ringard.

D'ailleurs l'avenir c'est clairement le langage Julia qui n'a que des avantages, C++ est en train de se Coboliser, mais bon cela restera une bonne source de revenus pour la maintenance de l'existant pour ceux qui aiment les langages antiques compliqués ... :mrgreen:

Citation:

---

Envoyé par Mingolito

C'est pas mal, mais bon le C++ est très en retard est encore très loin de pouvoir rattraper l'énorme avance du C# qui est bien plus moderne et surtout bien mieux foutu, le C++ reste un langage désuet et ringard.

D'ailleurs l'avenir c'est clairement le langage Julia qui n'a que des avantages

---

Comparé aux autres langages connus de haut niveau comme Java et C#, C++ est en retard sur certains points, mais il est en avance sur d'autres, surtout quand on a besoin d'avoir de bonnes performances.

Du côté des langages émergents, peut-être que Julia s'imposera dans les applis qui n'auront pas besoin de performances aussi élevées qu'avec du C++ optimisé. Mais, tant que Julia nécessitera d'utiliser un ramasse-miettes, il ne sera pas un vrai concurrent du C++. Le futur concurrent le plus sérieux du C++ me semble être Rust.

il y a eu de gros débats houleux sur les modules, les coroutines, les contrats, mais pour l'intant, les 3 sont dedans ! Et il n'y a je crois aucun mort à déplorer pendant cette réunion :)

Je suis pas d'accord avec le fait que C++ est en retard par rapport aux autres langages comme C# ou Julia sachant que C++ est complètement à part par rapport à ces langages. Déjà C++ permet de faire pas mal de choses que les autres langages ne permettent pas (alors que l'inverse n'existe pas, c'est juste que ça peut être compliqué à faire :lol:). Surtout que maintenant avec la standardisation de C++ et la librairie STL qui va avec, c'est un langage qui est puissant, sophistiqué, et surtout performant. Après même si Julia à l'air plutôt sympa, et même avoir des performances proche de C++, je pense pas que l'on puisse envisager de migrer des projet de C++ vers Julia. Et je ne pense pas non plus que les gens vont lâcher C++ au profit de Julia ou de C# (surtout pour le C# qui est plus un concurrent pour Java). D'ailleurs, l'argument comme quoi Julia a des performances proche de C++, je pense qu'on peut assez vite s'en éloigner si on arrive sur des projets qui commence à être complexe (à condition d'utiliser correctement les mécanisme du C++ visant à optimiser son programme, et on peut aller encore plus loin si on décide d'être vraiment bas niveau, et donc d'éviter au maximum d'utiliser la librairie STL). De plus, sur certaines applications, le garbage collector ça pose vite des problèmes pour les performances. Par contre Julia sera surtout un concurrent pour Python, ce qui est une très bonne chose. D'ailleurs tu remarqueras aussi que pour faire de la programmation système C et C++ n'ont pas vraiment de concurrent :lol:

Sinon, je voulais savoir, est ce que c'est dans C++20 qu'ils ont prévu de pouvoir restreindre les types génériques (comme en Java par exemple) ?
Et est ce que c'est prévu qu'ils règlent le problème où l'ont doit inclure le fichier source dans le header quand on fait de la généricité ? C'est le côté moche du C++ je trouve :weird: Surtout que du coup on ne peut pas faire du using namespace dans le fichier source au quel cas cela va se répercuter dans les autres fichiers sources.

Citation:

---

Envoyé par G_EREMY

Déjà C++ permet de faire pas mal de choses que les autres langages ne permettent pas (alors que l'inverse n'existe pas, c'est juste que ça peut être compliqué à faire :lol:).

---

Quoi, par exemple ? Je n'ai en tête que des syntaxes spécifiques que C++ autorise (merci les templates), mais pas de fonctionnalité qu'un autre langage ne saurait pas implémenter (peut-être pas avec la même performance, mais le C++ ne gagne pas non plus à tous les coups).

Citation:

---

Envoyé par dourouc05

Quoi, par exemple ? Je n'ai en tête que des syntaxes spécifiques que C++ autorise (merci les templates), mais pas de fonctionnalité qu'un autre langage ne saurait pas implémenter (peut-être pas avec la même performance, mais le C++ ne gagne pas non plus à tous les coups).

---

Bah déjà l'héritage multiple, l'héritage par spécialisation, le multi-thread, le multi-processus, et tout ce qui concerne le système. Après effectivement il n'y a pas de choses que C++ permet de "calculer" mais qui n'est pas calculable dans C#, Julia, etc...

Citation:

---

Envoyé par Mingolito

l'avenir c'est clairement le langage xxx qui n'a que des avantages

---

https://blog.daftcode.pl/hype-driven...t-3469fc2e9b22

Citation:

---

Envoyé par G_EREMY

Bah déjà (1) l'héritage multiple, (2) l'héritage par spécialisation, (3) le multi-thread, le multi-processus, et tout ce qui concerne le système.

---

1) La plupart supportent l'héritage multiple d'interface et l’injection de trait (directement à l'intérieur d'une classe ou de manière externe).
2) Du CRTP ? C'est vrai que de manière générale les autres langages sont plus limitants au niveau du fonctionnement des templates.
3) Ce n'est pas du ressort du C++, mais des bibliothèques. Après, pour les quelques mots clefs comme thread_local, je pense qu'on peut trouver des équivalents.

Citation:

---

utiliser correctement les mécanismes du C++ visant à optimiser son programme, et on peut aller encore plus loin si on décide d'être vraiment bas niveau, et donc d'éviter au maximum d'utiliser la librairie STL)

---

La STL est optimisation/bas niveau n'est pas incompatible. Il y a certaines parties qui peuvent être problématique, mais une bonne partie est censé être performant. Si ce n'est pas le cas, la meilleure chose à faire est de patcher les implémentations pour que tous le monde en profite.

Citation:

---

est-ce prévu de pouvoir restreindre les types génériques (comme en Java par exemple) ?

---

Les concepts devraient permettre cela. Actuellement on peut le faire avec std::enable_if/SFINAE ou des static_assert.

Citation:

---

Et est ce que c'est prévu qu'ils règlent le problème où l'on doit inclure le fichier source dans le header quand on fait de la généricité ?

---

Ce n'est pas possible pour plusieurs raisons:

- Le prototype peut dépendre de l'implémentation, par exemple avec une fonction qui retourne auto.
- Les instances de fonction template n'existe qu'au moment de leur utilisation. Pour les mettre dans un .cpp, il faudrait alors instancier les mêmes fonctions dans le cpp pour ne pas avoir des erreurs de link. On peut utiliser des instanciations explicite et extern(?), mais cela cause d'autre soucis pour une classe: toutes les fonctions doivent compiler, même si elles ne sont jamais utilisées.

Pour la séparation, le plus commun reste de mettre les implémentations dans un .tpl, tcc, .inl, .whatever et de l'inclure en fin du fichier d'en-tête.

Citation:

---

C'est le côté moche du C++ je trouve Surtout que du coup on ne peut pas faire du using namespace dans le fichier source auquel cas cela va se répercuter dans les autres fichiers sources.

---

Il doit bien y avoir moyen de le faire en jouant avec les namespaces

Code:

---

1 2 3 4 5 6 7 8 9 10

namespace malib { namespace impl { using namespace std; namespace v1 { // ... } } using namespace impl::v1; }

---

:aie:

Après perso, je préfère écrire le namespace ou mettre un alias dessus.

Citation:

---

Envoyé par Bill Fassinou

...
:fleche: Que pensez-vous de ces nouveautés de C++ 20 ?
...

---

Surtout intéressé par les modules (et le reste est aussi utile bien sur). On attend maintenant les compilateurs bien stabilisés qui gèrent tout ça.
Pour le réseau, c'est un peu dommage que ce ne soit pas intégré, mais ce n'est pas bien critique non plus, même si j'en aurais vraiment l'usage, ça fait longtemps qu'on a pris l'habitude d'utiliser des bibliothèques externes.

Citation:

---

Envoyé par G_EREMY

Sinon, je voulais savoir, est ce que c'est dans C++20 qu'ils ont prévu de pouvoir restreindre les types génériques (comme en Java par exemple) ?

---

Ce sont les concepts. Mais c'estg fait en respectant le duck-typing, ce qui est une force majeure des templates par rapport aux génériques du Java qui imposant aux paramètres de se déclarer génériques.

Citation:

---

Envoyé par G_EREMY

Et est ce que c'est prévu qu'ils règlent le problème où l'ont doit inclure le fichier source dans le header quand on fait de la généricité ? C'est le côté moche du C++ je trouve :weird: Surtout que du coup on ne peut pas faire du using namespace dans le fichier source au quel cas cela va se répercuter dans les autres fichiers sources.

---

Header ? Qu'est-ce donc que ça ? Maintenant, il y a les modules qui permettent une organisation efficace du code source. Bon, il faut encore attendre un peu que les compilateurs les implémentent bien et que les outils autour du langage se mettent à jour (ce qui n'est pas forcément trivial), mais le chemin est ouvert.

Citation:

---

Envoyé par jo_link_noir

1) La plupart supportent l'héritage multiple d'interface et l’injection de trait (directement à l'intérieur d'une classe ou de manière externe).

---

Oui bien sure heureusement que tous les langages orienté objets digne de ce nom permette l'héritage multiple d'interface :lol: moi je parlais d'héritage multiple de classe (plus le fait qu'il y a l'héritage multiple "par copie" et virtuel). Après je sais que par exemple PHP implémente les traits, mais en ce qui concerne C#, Java, Julia et Pyhton je sais pas, mais ça répond pas à tous les problèmes que l'héritage multiple résolve (après le principe est plutôt pas mal).

Citation:

---

Envoyé par jo_link_noir

2) Du CRTP ? C'est vrai que de manière générale les autres langages sont plus limitants au niveau du fonctionnement des templates.

---

Je parlais plus de choses comme Mixin (mais c'est vrai que CRTP aussi est intéressant comme mécanisme). Plus aussi le fait qu'on est libre de faire ce que l'on veut avec des types génériques.

Citation:

---

Envoyé par jo_link_noir

3) Ce n'est pas du ressort du C++, mais des bibliothèques. Après, pour les quelques mots clefs comme thread_local, je pense qu'on peut trouver des équivalents.

---

J'ai pas très bien compris, justement en C++ on peut faire des choses plus puissante (parce qu'on créer des threads et des sous-processus), plus les mécanisme comme les mutex, les sémaphores, et autres IPC. Par contre c'est vrai que la bibliothèque STL pourrait implémenter des choses pour éviter de "réinventer la roue" avec des mécanisme comme RMI par exemple.

Citation:

---

Envoyé par jo_link_noir

Les concepts devraient permettre cela. Actuellement on peut le faire avec std::enable_if/SFINAE ou des static_assert.

---

Oui effectivement, après je pense juste que ça serais mieux que ce soit dans la déclaration du template même, comme ça la restriction du type ce fait dans le fichier d'en-tête et non pas dans le source. Après ça reste mon avis.

Citation:

---

Envoyé par jo_link_noir

Ce n'est pas possible pour plusieurs raisons:

- Le prototype peut dépendre de l'implémentation, par exemple avec une fonction qui retourne auto.
- Les instances de fonction template n'existe qu'au moment de leur utilisation. Pour les mettre dans un .cpp, il faudrait alors instancier les mêmes fonctions dans le cpp pour ne pas avoir des erreurs de link. On peut utiliser des instanciations explicite et extern(?), mais cela cause d'autre soucis pour une classe: toutes les fonctions doivent compiler, même si elles ne sont jamais utilisées.

Pour la séparation, le plus commun reste de mettre les implémentations dans un .tpl, tcc, .inl, .whatever et de l'inclure en fin du fichier d'en-tête.

---

Je connais dans les "grandes lignes" le mécanisme qui se fait à la compilation pour les template (et que du coup un tpp n'est jamais compilé). Par contre je trouve ça dommage qu'ils aient pas trouver une solution pour remédier à ce "problème". Par exemple, on pourrait déclarer au compilateur quels sont les fichier tpp à utiliser, avec une commande du style:
[c]g++ -o exec file1.cpp file2.cpp filen.cpp -t temp1.tpp temp2.tpp tempn.tpp

Citation:

---

Envoyé par jo_link_noir

Il doit bien y avoir moyen de le faire en jouant avec les namespaces

Code:

---

1 2 3 4 5 6 7 8 9 10

namespace malib { namespace impl { using namespace std; namespace v1 { // ... } } using namespace impl::v1; }

---

:aie:

Après perso, je préfère écrire le namespace ou mettre un alias dessus.

---

Ah ouais merci pour l'astuce faudra que je teste ça. Sinon ce que je fais en temps normal c'est des using dans la déclaration de la classe mais c'est pas toujours très très pratique.

Citation:

---

Envoyé par JolyLoic

Ce sont les concepts. Mais c'estg fait en respectant le duck-typing, ce qui est une force majeure des templates par rapport aux génériques du Java qui imposant aux paramètres de se déclarer génériques.

---

Oui j'avais remarqué ça en C++, après pouvoir restreindre le type bah déjà ça permet d'éviter au projet de prendre une tournure où on fait "n’importe quoi", mais aussi de rendre le code plus lisible.

Citation:

---

Envoyé par JolyLoic

Header ? Qu'est-ce donc que ça ? Maintenant, il y a les modules qui permettent une organisation efficace du code source. Bon, il faut encore attendre un peu que les compilateurs les implémentent bien et que les outils autour du langage se mettent à jour (ce qui n'est pas forcément trivial), mais le chemin est ouvert.

---

faudra que je me renseigne sur ce sujet alors :lol:

Citation:

---

Envoyé par G_EREMY

Je connais dans les "grandes lignes" le mécanisme qui se fait à la compilation pour les template (et que du coup un tpp n'est jamais compilé). Par contre je trouve ça dommage qu'ils aient pas trouver une solution pour remédier à ce "problème".

---

Si la solution existe depuis 2003 :mrgreen: :mrgreen: ... avec l'ajout du mot-clef "export" dans la norme (<- qui fut un énorme four :whistle: ou :aie:)

Mais justement le développeur d'un compilateur C++ (Digital Mars ???) avait été le seul à le supporter et avait partagé le bouzin à coder le truc.

Le problème c'est que si une partie d'un projet ou un projet modifie un template, il faut [répercuter les changements]/ [vérifier les autres endroits] où est utilisé le template.
Actuellement c'est fait à chaque compilation :mrgreen:

Citation:

---

Envoyé par foetus

Si la solution existe depuis 2003 :mrgreen: :mrgreen: ... avec l'ajout du mot-clef "export" dans la norme (<- qui fut un énorme four :whistle: ou :aie:)

Mais justement le développeur d'un compilateur C++ (Digital Mars ???) avait été le seul à le supporter et avait partagé le bouzin à coder le truc.

---

Je crois que c'est le Front-End d'EDG qui l'a implémenté. Je sais pas si les compilateurs qui l'utilisent ont suivi (Intel?). En tous cas c'est l'effort démesuré pour implémenter cette feature qui a fait qu'elle a été retirée de la norme.

Mais sinon pour le côté "archaïque" du mécanisme d'inclusion en C++, cette norme 2020 est censée amorcer le virage vers quelque chose de plus moderne grâce aux modules. Encore un peu de patience... :)

Code:

---

1 2 3 4 5 6 7

import std.core;   int main() { using namespace std; vector<string> v { "Plato", "Descartes", "Bacon" }; copy(v.begin(), v.end(), ostream_iterator<string>(cout, "\n")); }

---

https://devblogs.microsoft.com/cppbl...l-studio-2017/

qu'est ce que j'aimerais qu'il y ait un nettoyage de la syntaxe du c++, le langage est bien, mais stupidement complexe à écrire, et plus ça va, plus on ajoute des syntaxes illogiques sur un socle stupide ;
les excuses habituelles de la rétrocompatibilité et de faire évoluer son code ne tiennent pas une seule seconde.

qu'est ce qui est passé par la tête du comité pour se dire que par exemple ça : virtual int foo() override
c'est acceptable niveau syntaxe? (et ça c'est encore gentillet comme exemple de stupidité)

combien de fois j'ai lu des articles de pontes du c++ qui disent que la syntaxe pour telle fonctionnalité est stupide.

je vois souvent des moqueries sur la syntaxe de javascript, bah ça y est, on a les mêmes absurdités en c++.

on rajoute des fonctionnalités à c++, cool, mais à quel prix en terme d'écriture...

Citation:

---

Envoyé par stardeath

les excuses habituelles de la rétrocompatibilité et de faire évoluer son code ne tiennent pas une seule seconde.

---

Pourquoi ?

Je ne vois pas comment on pourrais se passer, au moins à court terme (et donc sur une ou deux versions successives), de rétrocompatibilité. Et donc il n'est pas anormal de continuer à supporter des syntaxes anciennes bien que gênantes.

Citation:

---

Envoyé par stardeath

qu'est ce qui est passé par la tête du comité pour se dire que par exemple ça : virtual int foo() override
c'est acceptable niveau syntaxe? (et ça c'est encore gentillet comme exemple de stupidité)

---

Autant je suis d'accord qu'il existe des syntaxes qui, au moins en partant d'une feuille blanche, pourrait être grandement améliorer, autant ici je ne vois pas vraiment de souci. Sachant en outre que le virtual est ici inutile et que le code effectivement écrit serait plus certainement int foo() override

sauf que là, on est pas sur 1 ou 2 version de rétrocompatibilité, mais sur une rétrocompatibilité presque totale, sauf des fois, où le comité casse une rétro out of nowhere.
et le pire étant une compatibilité avec le c, qui ne ce justifie pas vu la différence de langage et surtout la totale différence d'évolution du c.

le problème de garder des syntaxes gênantes, c'est ce que j'énonce, c'est que tu vas rajouter une incohérence supplémentaire sur un truc déjà bancal pour whatever raison ;

pour reprendre mon example, virtual int foo() override, avec le virtual devant (l'omettre est pour moi une très mauvaise pratique, vu que le override est ailleurs dans le code) les mots clés/mots clés contextuels donnant des informations sur un seul aspect du langage sont à 2 endroits différents dans le code, totalement en contradiction avec le simple fait d'écrire au même endroit les trucs qui concerne la même chose.

de plus, selon comment le comité est luné (désolé de prendre le comité pour une seule entité, mais c'est plus court à écrire et à expliciter ma pensée), dixit les membres du comité, des fois ils vont "se résoudre" à ajouter des mots clés décorés genre "co_yield", pour n'en citer qu'un, et là pour le cas du override, ils vont en faire un mot clé contextuel à un endroit étrange dans le code. pourquoi, pour ne pas avoir de collision, avoir choisi par exemple vi_override, pour garder une cohérence ; donc avec mon exemple complet :

virtual vi_override int foo()

et là, je trouverai cohérent d'omettre le virtual, vu que l'autre information complétant la "virtualité" de cette fonction ce trouve au strict voisinage donc : vi_override int foo().

pour continuer sur des exemples d'incohérences, je mets d'autres exemples :

- final et override en mot clé contextuel, à l'opposé du placement de virtual ;
- co_await, co_return et co_yield, décoré avec le préfix "co_" ;
- __has_include, décoré avec le préfix "__" ;
etc.

le problème que ça cache selon moi, c'est qu'il n'y a personne dans le bateau pour essayer de donné au langage une cohérence d'écriture.
autant avec les anciennes features, je peux comprendre qu'on ne puisse pas les reprendre, autant depuis c++11 on devrait avoir une instance dans le comité pour garder une cohérence dans l'écriture des nouvelles fonctionnalités, avec par exemple que les problèmes de collisions de noms avec les bases de code existantes, soit résolus en utilisant les mêmes moyens.

non seulement au niveau du développeur, ça fait une spécification incohérente à lire/retenir/utiliser ; quand tu écris des outils d'analyses du c++, la grammaire à écrire/traiter est juste inbouffable et propice aux erreurs.

pour moi la solution aurait été d'avoir la possibilité d'indiquer par un quelconque moyen la version de c++ à utiliser par fichier à la compilation et donc de faire évoluer son code, non pas en mettant l'ancien et le nouveau code dans un seul et même fichier, mais en les mettant dans différentes unités de compil, ça aurait selon moi été une contrainte moins gênante que l'espèce de château de carte avec lequel on est rendu.

je dis pas que c'est une solution parfaite, loin de là, mais avec le c++ tel qu'il évolue, on est quand même de plus en plus loin d'un langage agréable à utiliser, puissant certes, mais stupidement débile à écrire.