Discussion :

[Bill Fassinou]

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.

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 ?

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

Voir aussi

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

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

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

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

[ParseCoder]

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:

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

[Pyramidev]

Enfin les modules !!!

[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, 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 ...

[Pyramidev]

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.

[JolyLoic]

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

[Aurelien.Regat-Barrel]

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

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

[G_EREMY]

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 ). 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

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 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.

[dourouc05]

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 ).

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).

[G_EREMY]

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...

[jo_link_noir]

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.

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.

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.

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.

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
namespace malib {
  namespace impl {
    using namespace std;
    namespace v1 {
      // ...
    }
  }
  using namespace impl::v1;
}

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

[G_EREMY]

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 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).

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.

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.

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.

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

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
namespace malib {
  namespace impl {
    using namespace std;
    namespace v1 {
      // ...
    }
  }
  using namespace impl::v1;
}

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.

[JolyLoic]

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.

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 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.

[G_EREMY]

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.

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

[wolinn]

...
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.

[TawalMc]

Anh le C# voilà , j'oubliais qu'il continue d'exister (https://www.developpez.net/forums/im...ilies/ptdr.gif). Bof de là à vouloir mettre C# devant le C++, bof c'est vraiment osé. Laisse le C# avec son concurrent Java qu'il n'arrive pas encore à surpasser avant d'en venir au C++. Un langage qui est presque restreitn à une plateforme bof. Et dire qu'il ya des dommaines où il est presque inexistant et ne fait pas le poids une seconde face au Cpp.
J'aimerais bien voir Julia et ses évolutions !!
Tous les concureents possible , mais pas C# svp...
Vive l'évolution dun C++ , et vive ses concurrents (espéront qu'ils tiennent). https://www.developpez.net/forums/im.../icon_cool.gif

[Mingolito]

C# est maintenant plus ou moins multiplateformes (avec Xamarin, mono, etc).
En France C# est devant C++ sur les offres d'emploi.



Bon enfin trollage à part C++ reste le langage de choix pour les éditeurs de logiciels et certains domaines d'applications...

[Bill Fassinou]

La spécification du C++ 20 a été approuvée à l'unanimité, elle succèdera à C++ 17
et apporte bon nombre de nouveautés dont les Modules, les Coroutines et autres

Mise à jour du 07/09/2020 : Samedi dernier, le projet de normes ISO/IEC 14882:2020 a été approuvé en tant que dernière mise à jour majeure du langage de programmation C ++. Le vote sur le DIS (Draft International Standard) du C++20 s'est achevé le vendredi, et il a été adopté à l'unanimité. L'approbation du C ++ 20 a été unanime et constitue une mise à jour très importante par rapport à C ++ 17. Cela signifie que le C++20 a maintenant reçu l'approbation technique finale et qu'il a été soumis au vote de l'ISO.

Il sera officiellement publié vers la fin de 2020, après un dernier cycle de travail éditorial de l'ISO. Même s'il arrivait qu'il soit publié en 2021, il sera toujours appelé C++20, car le WG21 a terminé ses travaux techniques en février. En résumé, C ++ 20 apporte les Modules, les Coroutines, l’ajout de l’opérateur ⇔ à la bibliothèque standard, les Concepts et autres.

Comme annoncé en février dernier, le comité ISO C++ 20 a tenu sa réunion d’été la semaine passée à Cologne, en Allemagne. Le compte rendu de la réunion indique que les travaux sont achevés pour le C++ 20 et un brouillon sera diffusé avant la fin de l’été. Au cours de la réunion, quelques ajouts et modifications ont été apportés au brouillon du C++ 20 présenté en février dernier par le comité. La norme internationale C++ 20 est prévue pour être publiée officiellement en février 2020 à Prague.

Au cours de la précédente réunion de février, le comité ISO C++ 20 avait ajouté plusieurs nouvelles fonctionnalités au langage. Parmi ces fonctionnalités figurent les Coroutines et les Modules. Les Modules constituent une nouvelle alternative aux fichiers d’entê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. Les Coroutines sont des fonctions qui peuvent suspendre et reprendre leur exécution tout en conservant leur état.

À l’issue de la réunion de la semaine passée, il a été rapporté que quelques ajouts et modifications ont de nouveau été apportés à la spécification C++ 20. Selon le compte rendu présenté sur Reddit, de nouvelles fonctionnalités ont été ajoutées et de nombreuses modifications ont également été apportées. Parmi les nouveaux ajouts, on peut citer std::format, l’intégration de l’opérateur ⇔ dans la bibliothèque standard du langage, etc., et les conteneurs constexpr. Herb Sutter, le président de comité de normalisation de la norme C++ 20, a apporté plus d’explications sur ces nouveaux ajouts :

std::format

std::format ajoute la prise en charge des chaînes de format à la bibliothèque standard C++, y compris pour les paramètres de type sécurisé et de position. Si vous connaissez les chaînes au format Boost.Format ou POSIX, ou même simplement printf, vous saurez exactement de quoi il s'agit. Selon lui, std::format donne le meilleur de printf (commodité) et le meilleur de iostreams (sécurité et extensibilité des iostreams), mais il ne se limite pas à iostreams. Il vous permet également de formater n’importe quelle chaîne. « Cela fait longtemps que j'attends cela, de sorte que je n'aurai plus jamais à utiliser l’entête iomanip », a-t-il déclaré à propos.

Stop Token and Joining Thread

Sutter a expliqué que cette fonctionnalité introduit deux nouveaux concepts. Premièrement, il s’agit d’un type de thread dont le destructeur se joint implicitement si vous ne vous êtes pas encore connecté ou détaché. Et deuxièmement, mais plus important encore, cette fonctionnalité constitue un mécanisme d'annulation composable général dans la bibliothèque standard que tous les types peuvent utiliser. Ce mécanisme porte le nom de stop_token.

Les conteneurs constexpr

Les conteneurs constexpr suivants ont été ajoutés à la norme C++ 20 : constexpr INVOKE, constexpr std::vector et constexpr std::string. Selon Sutter, cela signifie que beaucoup de code C++ ordinaire peut être exécuté à la compilation, y compris même les conteneurs vectoriels et chaînes dynamiques standard. « C’était quelque chose qui aurait été difficile à imaginer il y a quelques années à peine, mais cela montre de plus en plus que nous sommes sur un chemin où nous pouvons exécuter du code C ++ simple au moment de la compilation au lieu d’essayer d’exprimer ces calculs sous forme de métaprogrammes de modèle », a-t-il précisé à propos de ces ajouts.

L’utilisation des énumérations a été revue

Selon les explications sur la fonctionnalité, les énumérations dont il s'agit ici ne sont pas des classes. Ils sont plus proches des espaces de noms comprenant des variables en ligne. La syntaxe familière qui fonctionne pour les espaces de noms devrait donc également leur être appliquée, d’une manière ou d’une autre. Comme ils sont fermés, petits et ne contiennent pas de jeux de surcharge, l’on peut mieux faire que la directive using pour les espaces de noms et obtenir les identifiants dans la portée locale. L'introduction de cette fonctionnalité permettra de mieux nommer les énumérations.

Actuellement, les énumérations sont nommées avec un identifiant aussi court que possible, souvent jusqu'à l'absurdité, lorsqu'ils sont réduits à des abréviations totalement non descriptives. Avec cette fonctionnalité, les identifiants deviennent disponibles pour une recherche non qualifiée dans des contextes locaux où leur source est évidente, ce qui permet à l'utilisateur de l'énumération de contrôler le style de recherche au lieu de créer une sémantique de recherche dans le type de l'énumération.

Certaines modifications ont également été apportées au cours de la réunion de la semaine passée. Les Contrats ont été transférés de C++ 20 à un autre groupe d’étude. Selon Sutter, lors de cette réunion, il est apparu clairement que le comité n’a pas encore fini de concevoir les Contrats à temps pour C ++ 20. « Lorsque nous avions adopté la fonctionnalité il y a un an, nous pensions qu'elle était prête pour la norme, mais depuis lors, nous avons découvert des désaccords de conception persistants et des préoccupations que nous ne pouvions pas résoudre suffisamment pour obtenir un consensus (accord général sans objections soutenues). Les principaux soumissionnaires ont unanimement convenu que la bonne chose à faire est de différer sa publication », a-t-il déclaré.

Cependant, les Contrats sont une caractéristique importante, et les travaux sur celles-ci n’arrêtent pas, mais continuent. « J'espère que lors des prochaines réunions, nous ferrons de solides progrès dans ce domaine important », a-t-il expliqué à propos. Les composantes de la norme C++ 20 sont à présent connues. Un brouillon de comité sera publié dans les prochaines semaines et la publication officielle du C++ 20 est prévue pour le mois de février 2020. Voici une liste non exhaustive des fonctionnalités notables qui sont attendues pour C++ 20 :

• les Modules ;
• les Coroutines ;
• l’ajout de l’opérateur ⇔ à la bibliothèque standard ;
• les Concepts ;
• les Ranges ;
• les conteneurs constexpr ;
• les macros de test de fonctionnalité ;
• std::span ;
• std::format ;
• std::atomic_ref ;
• etc.

Sources : Rapport du Comité C++, Herb Sutter

Et vous ?

Que pensez-vous des fonctionnalités apportées à C++ 20 ?
Quelles autres fonctionnalités auriez-vous souhaité avoir pour le C++ 20 ?

Voir aussi

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 réunion d'automne du comité WG21 sur l'ajout de fonctionnalités au C ++ 20 est achevée. Voici quelques nouveautés introduites au langage

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

[Matthieu76]

C'est vraiment dommage que les contrats soit décalé, c'est la feature qui me hypait le plus et de loin.

[onilink_]

Oui, mais bon il vaut mieux l'avoir plus tard que maintenant avec des problèmes
Surtout que c'est remplaçable (certes pas de manière aussi efficace) à coup de macros.

Puis on a pas mal de trucs vraiment cool, rien que les concepts ça va vraiment changer la façon de programmer...

Perso j'attendais surtout la réflexivité avec impatience.