Gel des fonctionnalités C ++ 20. Coroutines, modules et plus

L'autre jour, il y a eu une réunion du comité international de normalisation C ++ dans la ville américaine de Kona. Ce n'était pas seulement une réunion, mais un gel des fonctionnalités! Aucune nouvelle idée sérieuse ne peut plus s'infiltrer dans la norme, il ne reste que quelques réunions pour ajouter des choses pré-approuvées, corriger les lacunes et éliminer les rugosités.

Si des modules et des corutins sont attendus en C ++ 20, y aura-t-il une bibliothèque rapide pour formater la sortie, pourra-t-il travailler avec des calendriers, ajoutera-t-il std :: stacktrace , le compilateur commencera-t-il à appeler std :: se déplacer lui-même dans certains cas, acceptera-t-il std :: flat_map ? Tout cela et bien plus vous attend sous la coupe.

Coroutines TS

Le débat le plus chaud a éclaté autour des coroutines. Le comité a dû considérer trois approches différentes des coroutines et décider d'accepter les Coroutines TS existantes en tant que norme, ou d'opter pour une voie différente.

Le choix n'a pas été facile, chaque approche a ses inconvénients et ses avantages:

• N4775 :
  
  • + il n'y a aucune restriction sur le fait que les coroutines doivent être décrites dans le fichier d'en-tête
  • - il n'y a aucune garantie stricte qu'il n'y aura pas d'allocation dynamique
  • ± pas l'interface la plus simple ( P1477R0 corrige cela)
  • - mots-clés moches co_await et co_yield (la phrase P1485R0 du WP21 corrige cela)
  • + 3 ans appliqués en pratique
  
  
• P1063R2 :
  
  • + pas d'allocations dynamiques
  • - les coroutines doivent être décrites dans le fichier d'en-tête ou vous devez vous tromper avec l'effacement de type vous-même
  • - des opérateurs clés encore plus effrayants [<-] et [->]
  • - pas de prototype fonctionnel
  • - pas l'interface la plus simple pour créer des choses asynchrones
  
  
• P1430R0 :
  
  • + pas d'allocations dynamiques
  • - les coroutines doivent être décrites dans le fichier d'en-tête ou vous devez vous débrouiller avec effacement de type vous-même
  • + pas de mots clés effrayants, tout est fluide
  • + Les utilisateurs de Corutin ne voient pas l'intérieur effrayant de la coroutine (ne voient même pas les analogues de co_await, tout fonctionne hors de la boîte)
  • - la première proposition, qui n'a jamais été discutée, nécessite un tas d'améliorations
  • - il est impossible de mettre en œuvre sur les technologies actuelles (nécessitent un support pour les structures de taille dynamique), nécessitent des coûts de main-d'œuvre énormes pour mettre en œuvre
  • ± un peu comme des nouilles de rappel
  
  

Après de longs débats, les coroutines ont été adoptées en C ++ 20 comme elles l'étaient dans Coroutines TS (avec les préfixes co_ * et les anciens points de personnalisation).

Modules

La discussion des modules a été influencée par un document intéressant avec des mesures de performance:
P1441R0 . Les résultats peuvent être interprétés de différentes manières: des "systèmes d'assemblage existants et la mise en œuvre des modules ne sont pas encore suffisamment optimisés" à "les modules ne s'adaptent pas bien à la complexité croissante du projet".

En plus de ce document, le comité a discuté d'un certain nombre de changements mineurs aux modules actuels. En conséquence, après 15 ans de discussion, de prototypage et d'expérimentation des implémentations, les modules ont été adoptés en C ++ 20.

Format

Bonne nouvelle à tous! Si vous ne trouvez aucun défaut fatal dans le sous-groupe Library, alors en C ++ 20, il sera possible de formater les chaînes en toute sécurité et très rapidement. Dites adieu à std :: ios , std :: locale et aux autres horreurs des années 90! Python a maintenant une syntaxe similaire pour le formatage en C ++: P0645R5 .

De plus, la proposition d'intégrer la nouvelle mise en forme et les nouveaux calendriers P1361R0 a été acceptée . Si tout se déroule comme prévu, les dates peuvent être affichées de manière humaine!

Réseaux, exécuteurs et propriétés

Les exécuteurs sont une brique importante pour prendre en charge la mise en réseau en C ++ hors de la boîte. Les exécuteurs ont besoin de Propriétés - la possibilité de modifier le type de données, en fonction du paramètre transmis au stade de la compilation, sans changer le concept du type.

Les propriétés sont décrites dans P1393R0 . Malgré le fait que le texte à inclure dans la norme ne compte que quelques pages, la proposition a provoqué des discussions animées. La proposition vous permet de créer des points de personnalisation presque omnipotents, de modifier le comportement de toutes les fonctions à l'aide des propriétés.

Par conséquent, il a été décidé d'inclure les propriétés dans le langage uniquement en C ++ 23 et, par conséquent, les exécuteurs et la mise en réseau en C ++ 20 n'apparaissent pas.

Autre

Les modifications suivantes ont déjà été apportées au projet C ++ 20:

• Les structures sans constructeurs (agrégats) peuvent désormais être initialisées à l'aide des parenthèses P0960 . En pratique, cela signifie que désormais std :: make_shared , std :: make_unique , std :: * :: emplace * fonctionneront correctement avec les agrégats sans erreurs de compilation
• Ajout de fonctions Lerp pour l'interpolation linéaire P0811
• Ajout de la possibilité de vectoriser les algorithmes de la bibliothèque standard P1001
• Les méthodes std :: span renvoient désormais les types non signés (similaires à l'ensemble de la bibliothèque standard) + la fonction std :: ssize a été ajoutée pour obtenir la taille du conteneur sous la forme d'un numéro signé P1227
• Les conteneurs non ordonnés ont appris à rechercher des valeurs à l'aide d'un hachage pré-calculé de P0920

Beaucoup d'autres choses attendent la révision finale dans les sous-groupes Bibliothèque et Core pour inclusion dans C ++ 20:

• Attente effective sur std :: atomic; classes de sémaphore et de barrière P1135
• std :: flat_map P0429
• std :: flat_set P1222
• std :: function_ref P0792
• constexpr pour <cmath> et <cstdlib> P0533
• std :: ranges :: to <any-container> pour stocker une plage de valeurs dans un conteneur P1206
• La capacité d'extraire efficacement des chaînes de std :: * stringstream et de transférer des chaînes personnalisées P0408
• Modifications multiples pour l' opérateur <=> , plages, constexpr

Les mérites de RG21

Le tout premier jour, le sous-groupe Core a repris la proposition bien-aimée de Yandex.Taxi pour le Stacktrace P0881R3 . Les commentaires sur la conception ont été discutés plus en détail dans le sous-groupe LEWG, une fois encore élaboré dans Core. En conséquence, des corrections ont été apportées tout au long de la semaine et des discussions ont eu lieu. La proposition n'est pas encore incluse dans le projet de norme, mais elle devrait l'être en C ++ 20 (s'ils trouvent soudainement un défaut fatal).

Avant de discuter de notre idée de P1485R0 pour apporter des mots clés pour coroutine, elle n'est pas arrivée à une conclusion.

Toujours à SG1, Concurrency a discuté de l'idée d'une carte P0652R2 simultanée non ordonnée. On nous a demandé de vérifier que l'API proposée évite les conflits avec les lecteurs. Ils ont également dit d'enquêter sur les conteneurs non commandés simultanés qui n'ont pas la fonction d'effacement et ne protègent pas la valeur du conteneur contre une modification concurrentielle.

L'offre de ZaMaZaN4iK de spécialiser std :: hash pour différentes classes de la bibliothèque standard P1406R0 a été décidée à être sévèrement réduite. Le comité a recommandé de laisser les spécialisations uniquement pour std :: pair , std :: tuple , std :: array et std :: basic_string des allocateurs d'utilisateurs.

Dans un sous-ensemble de nombres, SG6 a discuté d'un mécanisme pour l'interaction de diverses nouvelles classes de nombres P0880R2 . La proposition vous permet de spécialiser deux modèles, d'obtenir un ensemble complet d'opérations mathématiques et de comparaisons pour tous les nouveaux types. Après la discussion, ils ont décidé d'essayer d'étendre le mécanisme afin qu'il puisse être utilisé non seulement pour les besoins de la bibliothèque standard, mais aussi que les utilisateurs puissent utiliser ces opérateurs pour leurs types.

Nous avons également discuté de nos suggestions mineures, y compris la macro de test de fonctionnalités P1424R0 et les politiques pour les ajouter à la norme.

Nous avons rapidement discuté de notre idée de permettre au compilateur de supprimer les copies inutiles de R0889R1 . On nous a dit de continuer à travailler dans ce sens et avons donné des exemples qui ne devraient pas rompre avec les nouvelles règles.

Au lieu de totaux

C ++ 20 sera tout aussi radicalement différent de C ++ 17 que C ++ 11 sera différent de C ++ 03. Un grand nombre de nouvelles technologies et de nouveaux paradigmes: concepts, contrats, gammes, modules, coroutines, conteneurs constexpr et polymorphisme dynamique constexpr, "nibloïdes", etc.

Bientôt, nous, Groupe de travail 21, publierons des commentaires sur un projet de norme C ++ 20. Par conséquent, si vous avez des douleurs ou si vous n'êtes pas d'accord avec une innovation, veuillez laisser vos réflexions sur cette page .

La prochaine réunion du comité international aura lieu à l'été, au cours de laquelle des innovations pour C ++ 23 pourraient commencer à être envisagées. Si vous voulez changer quelque chose en C ++ ou proposer votre idée, vous pouvez toujours écrire sur https://stdcpp.ru/ , où des gens du WP21 vous aideront à transmettre vos désirs au comité.

Voulez-vous nous parler en direct? Une réunion ouverte de RG21 se tiendra bientôt, restez à l'écoute pour les annonces sur events.yandex.ru . Retrouvez-nous également lors de la conférence C ++ Russia d' avril à Moscou.