Discussion :

[Aiekick]

toutes ces nouvelles fonctionnalités ne vont t'elles pas compliquer un peu plus les compilateurs, voir comme l'abus des templates creer des temps de compilation hyper long ?
peut t'il y avoir un impact perf ?

la feature "module" c'est comme les imports en java ou en C# ?

[boumchalet]

Bonjour,
Pour moi, après avoir travaillé avec des langage multiples (java, c#, Rust, Basic, Pyhton, ... plus de 40), c++ reste à une place particulière :
- c'est seule langage qui n'impose pas de limite entre les concepts hard et les abstractions de hauts niveaux, mais cela peut avoir un coût élevé (formation, investissement) => Il existe énormément de paradigmes de programmation c++, deux programmeurs c++ peuvent ne pas se comprendre.
- Bien qu’il soit possible d’intégrer des programmeurs de langages managés dans un projets c++, il est nécessaire de leur fixer un cadre strict (par exemple interdiction du new et delete)
- Beaucoup des langages qui ont limité les concepts pour simplifier la programmation, ils sont aujourd’hui engagés dans des impasses évolutives, par exemple : java . Ce n’est pas le cas du c++, ce qui lui permet d’évoluer vers la simplification sans coût supplémentaire.
Conclusion :
Il reste encore beaucoup de chose à faire en c++, il n’a pas atteint ces limites et reste un langage d’avenir pour manipuler notre monde. Il n’a pas d’équivalence.

[Pyramidev]

Bonjour,

Pour moi, après avoir travaillé avec des langage multiples (java, c#, Rust, Basic, Pyhton, ... plus de 40), c++ reste à une place particulière :
- c'est seule langage qui n'impose pas de limite entre les concepts hard et les abstractions de hauts niveaux

Quel sens donnes-tu à "pas de limite entre les concepts hardware et les abstractions de hauts niveaux" qui ferait que C++ respecte mieux ce principe que Rust (vu qu'il y a Rust dans ta liste) ?

Si tu fais référence au zero-overhead principle, ce dernier est mieux respecté en Rust qu'en C++. Par exemple :

• Pour faire de la propagation d'erreur de manière lisible, on n'est pas obligé de passer par des exceptions dynamiquement typées avec du RTTI. On a du sucre syntaxique sur les types qui implémentent le trait std::ops::Try comme std::option::Option et std::result::Result.
• Rust distingue std::sync::Arc qui est thread-safe de std::rc::Rc qui ne l'est pas et contrôle à la compilation qu'on ne passe pas à un thread un std::rc::Rc. Du côté de C++, l'équivalent est std::shared_ptr que les implémentations rendent thread-safe en pratique, même quand on ne fait pas de multithread. Le zero-overhead principle est aussi sacrifié pour les variables locales statiques dont l'initialisation doit être thread-safe depuis C++11, même si je me rappelle qu'il existe une option dans GCC pour passer outre cette règle du langage.
• En C++, quand un objet passe dans un moved from state, il faut quand même que son destructeur puisse être appelé sans faire de dégâts. En Rust, quand on fait l'équivalent d'un move (passage par valeur d'un objet qui n'implémente pas le trait std::marker::Copy qui signifie que la copie ne coûte pas cher, par exemple une copie d'un entier), l'objet n'est plus dans la portée. Il n'y a pas d'appel à drop (l'équivalent du destructeur) sur un objet "coquille vide". Rq : au passage, cela signifie aussi que la mise en place du RAII est mieux faite en Rust qu'en C++.

[boumchalet]

J'adore Rust et il a plein de qualité notamment pour la concurrence, le problème n'est pas là.
Des choix de conception ont été faits à juste raison (par exemple: match ,Valeur et mutabilité,Possession et emprunt).
Ces choix limiteront dans le futur son évolution, car c'est des contraintes. Ce qui en fait plus un DSL qu'un langage universel.
Pour l'instant les gains sont plus importants que les contraintes, mais je pense que cela ne sera pas toujours le cas.

NOTA Rust utilise LLVM c++ en backend

[Bill Fassinou]

C++ 20 est publié avec de nouvelles fonctionnalités pour le langage et la bibliothèque
de nouveaux mots clés et rend obsolètes certaines anciennes fonctionnalités

C++20 est le nom de la révision de la norme ISO/IEC pour le langage de programmation C++ après C++ 17. La norme a été techniquement finalisée par le GT21 lors de la réunion de Prague en février 2020, approuvée le 4 septembre 2020, et publiée par l'ISO au cours de ce mois. Notons que la norme ISO/CEI est un standard de sécurité de l'information publié conjointement par l'Organisation internationale de normalisation (ISO) et la Commission électrotechnique internationale (CEI, ou IEC en anglais). La nouvelle norme ISO C++ est officiellement connue sous le nom de norme internationale "ISO/IEC 14882:2020 - Langage de programmation C++".

Le C++ 20 ajoute plus de nouvelles fonctionnalités majeures que le C++ 14 ou le C++ 17. Les changements qui ont été acceptés ou dont l'inclusion dans le C++ 20 a été discutée sont les suivants :

Langage : nouvelles fonctionnalités linguistiques

• concepts ;
• modules ;
• les initialisateurs désignés (basés sur la caractéristique C99, et l'extension G++ commune) ;
• [=, this] comme une capture lambda ;
• template de listes de paramètres sur les lambdas ;
• opérateur de comparaison à 3 voies "<=>" également appelé "opérateur spaceship" ;
• l'initialisation d'une variable supplémentaire dans une instruction for basée sur une plage ;
• les lambdas dans des contextes non évalués ;
• les lambdas apatrides constructibles et cessibles par défaut ;
• permettre l'extension des paquets dans les captures lambda init ;
• des littéraux de chaîne comme paramètres de template ;
• suppression de l'obligation d'utiliser typename afin de lever l'ambiguïté des types dans de nombreux contextes ;
• nouveaux attributs standard : [[no_unique_address]], [[likely]] et [[unlikely]] ;
• "explicit" conditionnel : il permet au modificateur explicite d'être conditionnel à une expression booléenne ;
• "constexpr" étendu : fonctions virtuelles, union, try and catch, dynamic_cast et typeid, [85] std::pointer_traits ;
• fonctions immédiates utilisant le nouveau mot-clé "consteval" ;
• les entiers signés sont maintenant définis pour être représentés en utilisant le complément à deux (le dépassement des entiers signés reste un comportement non défini) ;
• un template de mémoire révisé ;
• diverses améliorations des liaisons structurées (interaction avec les captures lambda, durée de stockage statique et thread_local) ;
• coroutines ;
• ajout du mot-clé "constinit".

nouvelles fonctionnalités de la bibliothèque

Nouveaux en-têtes

• <concepts> ;
• <coroutine> ;
• <compare> ;
• <version>
• <source_location> ;
• <format> ;
• <span> ;
• <ranges> ;
• <bit> ;
• <numbers> ;
• <syncstream>.

Dans la bibliothèque de support Thread :

• <stop_token> ;
• <semaphore> ;
• <latch> ;
• <barrier>.

Nouvelles fonctionnalités de la bibliothèque

• macros de test des fonctionnalités de la bibliothèque ;
• bibliothèque de formatage ;
• bibliothèque du calendrier et du fuseau horaire ;
• std::source_location ;
• std::span ;
• std::endian ;
• prise en charge des tableaux pour std::make_shared ;
• std::remove_cvref ;
• std::to_address ;
• virgule flottante atomique , shared_ptr atomique ;
• classes de coordination des threads : std::barrier, std::latch, et std::counting_semaphore ;
• std::jthread et classes d'annulation de threads : std::stop_token, std::stop_source, et std::stop_callback ;
• std::osyncstream ;
• std::u8string et autres utilisations de char8_t ;
• constexpr pour <algorithm>, <utility>, <complex> ;
• std::string::starts_with / ends_with et std::string_view::starts_with / ends_with ;
• std::assume_aligned ;
• std::bind_front ;
• std::c8rtomb/std::mbrtoc8 ;
• std::make_obj_using_allocator etc ;
• std::make_shared_for_overwrite/std::make_unique_for_overwrite ;
• recherche hétérogène dans des conteneurs associatifs non ordonnés ;
• std::pmr::polymorphic_allocator avec des fonctions membres supplémentaires et std::byte comme argument de template par défaut ;
• std::execution::unseq ;
• std::midpoint et std::lerp ;
• std::ssize ;
• std::is_bounded_array, std::is_unbounded_array ;
• Ranges ;
• effacement uniforme des conteneurs : std::erase/std::erase_if, par exemple std::erase(std::list) ou std::erase_if(std::map), etc. ;
• constantes mathématiques dans <numbers>.

Mots-clés nouveaux et modifiés

De nombreux nouveaux mots-clés ont été ajoutés (et le nouveau "spaceship operator", opérateur <=>), tels que concept, constinit, consteval, co_await, co_return, co_yield, requires (plus un changement de sens pour l'exportation), et char8_t. En outre, "explicit" peut prendre une expression depuis C++20. La plupart des utilisations du mot-clé "volatile" ont été dépréciées. Outre les mots-clés, il existe des identificateurs ayant une signification particulière, notamment les nouveaux modules et importations.

Publié sous forme de spécifications techniques

• Parallélisme TS v2 (y compris les blocs de tâches) ;
• Mise en réseau TS v1 ;
• Reflection TS v1.

Reporté à une norme ultérieure

• les contrats : un nouveau groupe d'étude (SG21) a été formé pour travailler sur une nouvelle proposition ;
• la réflexion ;
• les métaclasses ;
• les exécuteurs testamentaires ;
• les extensions de réseau, y compris async, les services d'E/S de base, les timers, les tampons et les flux orientés vers les tampons, les sockets et les protocoles Internet (bloqués par les exécuteurs).

Fonctionnalités supprimées et dépréciation

Le C++20 a également supprimé certaines fonctionnalités, notamment :

• les en-têtes dérivés du C <ccomplex>, <ciso646>, <cstdalign>, <cstdbool> et <ctgmath> ont été supprimés, car ils ne servent à rien en C++. (Les en-têtes <*.h> correspondants restent, pour des raisons de compatibilité avec le C.) ;
• l'utilisation de throw() comme spécification d'exception a été supprimée ;
• certaines fonctionnalités de la bibliothèque, auparavant obsolètes, ont été supprimées, notamment std::uncaught_exception, std::raw_storage_iterator, std::is_literal_type, std::is_literal_type_v, std::result_of et std::result_of_t.

Les fonctionnalités dépréciées incluent :

• l'utilisation de l'opérateur virgule dans les expressions en indice a été dépréciée ;
• (la plupart des) "volatile" a été dépréciée.

Prise en charge du compilateur

Les développeurs des principaux compilateurs se sont préparés à la norme C++ 20 en mettant en place un support expérimental pour diverses fonctionnalités des versions préliminaires du C++ 20.

• Clang dispose d'une prise en charge partielle du C++ 20 qui peut être activée avec l'option -std=c++20 (version 10 et ultérieure) ou -std=c++2a (version 9 et antérieure) ;
• EDG eccp a commencé à mettre en œuvre les fonctionnalités du C++20 dans la version 5.0 et, à partir de la version 6.1, prend en charge la plupart des fonctionnalités du langage de base du C++ 20 ;
• GCC a ajouté un support partiel et expérimental du C++ 20 en 2017 dans la version 8 grâce à l'option -std=c++2a. Comme Clang, GCC a remplacé cette option par -std=c++20 dans la version 10. Il dispose également d'une option permettant d'activer les extensions GNU en plus du support C++ 20 expérimental, -std=gnu++20 ;
• Microsoft Visual Studio prend en charge certaines fonctionnalités du C++ 20 grâce à son option std:c++latest. Une option /std:c++20 permettant d'activer le mode C++ 20 est prévue dès que le compilateur aura terminé la fonctionnalité C++ 20.

Sources : Cppreference, ISO/CEI 14882:2020

Et vous ?

Que pensez-vous de la nouvelle norme du langage C++ 20 ?
Quelles fonctionnalités du C++ 20 attisent le plus votre curiosité ? Pourquoi ?

Voir aussi

Le comité ISO C++ a proposé une feuille de route pour C++ 23 et finalisé la nouvelle version du langage C++ 20, la norme devrait être publiée dans les mois à venir

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

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

[ParseCoder]

Avec les concepts, modules et coroutines c'est une excellente fournée!

[23JFK]

Va falloir que je me retape deux mille pages de spécifications.

[Invité]

Va falloir que je me retape deux mille pages de spécifications.

Pourquoi ? Tu développes ton propre compilateur ?

[23JFK]

Pourquoi ? Tu développes ton propre compilateur ?

J'suis psychorigide.

[onilink_]

Ça envoie du lourd cette nouvelle norme.
Dommage que je sois coincé en C++14.
Heureusement que certaines petites choses sont déjà accessibles, comme span de https://github.com/Microsoft/GSL

D'ailleurs j'ai pas trop suivis, mais qu'en est-il de l'unicode? C'est toujours autant le foutoir de parcourir une chaîne utf8 comme une liste chaînée?
Car dans mon cas je me suis retrouvé à ne pas passer par la bibliothèque standard, alors que ça me parait un peu essentiel comme feature (mais bon j'étais en C++11 quand j'ai eu le problème, j'imagine que ça a évolué).

[jo_link_noir]

D'ailleurs j'ai pas trop suivis, mais qu'en est-il de l'unicode? C'est toujours autant le foutoir de parcourir une chaîne utf8 comme une liste chaînée?
Car dans mon cas je me suis retrouvé à ne pas passer par la bibliothèque standard, alors que ça me parait un peu essentiel comme feature (mais bon j'étais en C++11 quand j'ai eu le problème, j'imagine que ça a évolué).

Il y a des propositions et des discussions (comme les résumé de réunion), mais ce n'est pas pour tout de suite. Je crois qu'en C++20 il n'y a eu aucun ajout pour manipuler de l'unicode/utf-8. Après, il faut bien comprendre que utf-8 n'est pas trivial, il y a plein de corner case et d'optimisation possible selon le besoin. Par exemple, juste comparer une chaîne n'est pas triviale si on accepte les représentations non canoniques, car un même caractère peut être représenté sous différent point de code. Et du coup plein de question arrivent sur comment gérer telle ou telle forme de caractère, la gestion d'erreur, etc. Selon le besoin, on peut assez facilement trouver des libs qui font le travail. Pour quelque chose de plus complet, il faut probablement regarder dans boost ou ICU.

Pour ceux intéressés, on peut trouver la liste des propositions ici: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/. La dernière colonne des tableaux indique si le papier est rejeté/accepté/rien. Le RX dans les numéros de papier fait référence au nombre de révision (P0211R3: papier 211 révision 3). Du coup, il vaut mieux lire les pages en commençant par le bas.

[jcop_fr]

Plus ça va, plus ça devient compliqué ...

Bientôt, faudra t'il Bac+20 pour savoir développer en C++ correctement ?

Vive le bon vieux C !

[Bktero]

J'ai commencé à m'intéresser ces dernières semaines à C++20 et franchement la liste des nouvelles fonctionnalités est vraiment hallucinante !

Le support par les principaux compilateurs (gcc, clang, msvc) commence à devenir très complet d'après ce tableau de cppreference : https://en.cppreference.com/w/cpp/compiler_support Depuis peu, gcc est devenu le premier à avoir implémenté toutes les fonctionnalités dites "core language"

Il y a des évolutions majeures dont le monde parle, comme les concepts et les ranges, il y a aussi plein d'ajouts super intéressants ! Personnellement, j'ai particulièrement apprécié std::span, qui me sera sûrement très utile pour m'interfacer avec du code C existant, ainsi que les nouvelles possibilités pour comparer les types (avec le spaceship operator et les =default sur les operateurs relationnels). Je suis aussi très pressé de voir des implémentations de std::format (qu'on peut utiliser pour l'instant avec la bibliothèque fmt). Et il faut aussi que j'explorer cette tripotée de trucs constexpr, parce que franchement des new constexpr, ça sonne dingue !

Franchement, il y a des belles choses dans cette version

A ceux qui disent que c'est trop compliqué, qu'il y a trop de trucs, je dirais trois choses :
1. tu n'es pas obligé de te servir des concepts si tu trouves ça trop compliqué
2. personne ne t'en voudra si tu ne connais pas std::is_constant_evaluated()
3. si tu as envie de coder std::span avec ton vieux C, je te regarde faire (laisse-moi juste le temps de prendre mon pop-corn)

[lefjuls]

Plus ça va, plus ça devient compliqué ...
Bientôt, faudra t'il Bac+20 pour savoir développer en C++ correctement ?

Je suis assez d'accord. Honnêtement j'ai perdu le fil depuis C++ 14.
A qui sont destinées ces nouveautés ?
Par exemple sur cppreference la première phrase sur les modules est : "Modules are orthogonal to namespaces". Ça ne donne pas envie d'aller plus loin.
Ou était-ce utile d'ajouter une "Three-way comparison" ?

j'ai un peu l'impression que c'est une vitrine la recherche informatique sur les langages de programmation. Le but est de caser toutes les notions possibles dans un langage.

[Pyramidev]

A qui sont destinées ces nouveautés ?
Par exemple sur cppreference la première phrase sur les modules est : "Modules are orthogonal to namespaces". Ça ne donne pas envie d'aller plus loin.

Les modules sont une fonctionnalité attendue depuis longtemps en C++. L'intérêt le plus visible est de réduire les temps de compilation dus en partie au système inefficace des #include pour simuler la modularité.
En effet, actuellement, quand un fichier ".h" qui n'appartient pas à un entête précompilé est inclus indirectement par n fichiers ".cpp", ce fichier ".h" est parsé n fois au lieu de une fois.
À une époque, on espérait avoir les modules en C++17. Quand ça a été reporté, une vidéo amusante avait recyclé le mème de Hitler :

Ou était-ce utile d'ajouter une "Three-way comparison" ?

Oui. L'intérêt de cette fonctionnalité, ce sont les performances.
Pour illustrer les problèmes de performance de l'opérateur < dans certains cas, prenons pour exemple le cas de la définition de < pour un tuple :

Compares lhs and rhs lexicographically by operator<, that is, compares the first elements, if they are equivalent, compares the second elements, if those are equivalent, compares the third elements, and so on.

For non-empty tuples, (3) is equivalent to

Code :

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

1
2
3
4
5
6
if (std::get<0>(lhs) < std::get<0>(rhs)) return true;
if (std::get<0>(rhs) < std::get<0>(lhs)) return false;
if (std::get<1>(lhs) < std::get<1>(rhs)) return true;
if (std::get<1>(rhs) < std::get<1>(lhs)) return false;
...
return std::get<N - 1>(lhs) < std::get<N - 1>(rhs);

Source : https://en.cppreference.com/w/cpp/ut...e/operator_cmp

On constate que std::get<0>(rhs) et std::get<0>(lhs) sont comparés deux fois (idem pour les autres indices sauf le dernier). Admettons que std::get<0>(rhs) et std::get<0>(lhs) sont des chaînes de caractères comparées par ordre lexicographique. Alors, pour ces deux chaînes, on parcourt deux fois au lieu d'une seule les premiers caractères identiques avant de tomber sur le caractère qui permet de dire quelle chaîne est plus grande que l'autre.

Par contre, pour l'opérateur <=>, pour chaque indice, il n'y a bien qu'une seule opération :

For non-empty tuples, (7) is equivalent to

Code :

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

1
2
3
4
if (auto c = synth_three_way(std::get<0>(lhs), std::get<0>(lhs)); c != 0) return c;
if (auto c = synth_three_way(std::get<1>(lhs), std::get<1>(lhs)); c != 0) return c;
...
return synth_three_way(std::get<N - 1>(lhs), std::get<N - 1>(lhs));

where synth_three_way is an exposition-only function object performing synthesized three-way comparison.

L'absence initiale de l'opérateur <=> est une erreur de jeunesse du C++ que le C++20 cherche à rattraper en retard.
En Rust, on a bien l'équivalent de <=> (std::cmp::Ord::cmp) pour définir une comparaison pour une relation d'ordre totale.

j'ai un peu l'impression que c'est une vitrine la recherche informatique sur les langages de programmation. Le but est de caser toutes les notions possibles dans un langage.

Non, en règle générale, le C++ intègre tard des fonctionnalités pour lesquelles on s'est rendu compte depuis longtemps qu'elles étaient utiles.