Discussion :

[CaptainDangeax]

Quelle guerre de chapelle entre C++ C# et Java. Un mot sur les garbage collector. Dans garbage collector, il y a garbage, c'est à dire déchets. Dans un projet récent, le produit avait des soucis de stabilité sur sa connexion BDD. Réunion avec les développeurs, revue des specs, ils m'expliquent qu'ils laissent les sockets ouvertes tout le temps d'exécution, et que le garbage collector gère toussa toussa. Je leur ai affiné les specs en leur indiquant à quel moment les sockets doivent être ouvertes ou fermées, et idem pour les fichiers de lock et les attentes dans les pollings. Résultat : plus d'instabilité. Donc quand j'entends parler de garbage collector, je sors mon flingue !
La querelle entre ces langages objets me fait bien rigoler aussi. Ce sont des concepts très lointains pour moi parce que moi, électronicien avec d'être ingénieur système, quand on me parle de pointeur, je sais ce que ça veut dire jusqu'aux signaux RAS CAS et R/_W des chips dram. Et tout ceci est au final compilé ou exécuté dans un environnement (pour Java ou C#). Peu importe le temps de compilation, peu importe le nombre de lignes, si au final le programme s'exécute plus vite et sans bug, et sans avoir à faire appel au garbage collector parce que le développeur a pensé à détruire ses objets une fois qu'il n'en avait plus besoin.
Enfin, C# et Java ne seront jamais aussi rapides que C ou C++ dès qu'il y a une grande quantité de calculs à faire derrière, ou un grand volume de données à manipuler.

[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 ?

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

[23JFK]

Pourquoi ? Tu développes ton propre compilateur ?

J'suis psychorigide.

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

[lefjuls]

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.

En relisant la discussion je pense comprendre ce qui me gêne. Je suis certain qu'il y a une bonne raison à l'ajout de toutes ces fonctionnalités, mais est-ce qu'un langage informatique à vocation à inclure toutes les fonctionnalités possibles ?
Comment apprend-on à développer en C++ en 2021 ? directement C++ 20 ou on commence par le C++(98) ? Car j'ai l'impression que selon la version le code produit n'aura pas grand chose à voir.

Autre question plus intéressée, a-t'on un premier recule sur la conversion d'un code existant à l'utilisation des modules ?
Par exemple est-ce qu'il y a une date de "migration" de la librairie boost ?

[Pyramidev]

En relisant la discussion je pense comprendre ce qui me gêne. Je suis certain qu'il y a une bonne raison à l'ajout de toutes ces fonctionnalités, mais est-ce qu'un langage informatique à vocation à inclure toutes les fonctionnalités possibles ?
Comment apprend-on à développer en C++ en 2021 ? directement C++ 20 ou on commence par le C++(98) ? Car j'ai l'impression que selon la version le code produit n'aura pas grand chose à voir.

En vrai, parmi les propositions d'enrichissement du C++, il y en a beaucoup plus qui sont rejetées que acceptées. Mais c'est vrai que, contrairement au langage C qui n'évolue quasiment pas, la complexité du C++ est toujours croissante. À ce sujet, Bjarne Stroustrup avait écrit Remember the Vasa!

[jo_link_noir]

Le problème du C++ est la trop grande volonté d'être rétrocompatible. Même si beaucoup de proposition vise à simplifier le langage ou le rendre plus performant, les anciens mécanismes restent et sont toujours utilisés. Du coup, le langage devient de plus en plus complexe et c'est difficile de rentrer dedans. Pour ne pas arranger le tout, la plupart des cours sont vieillissants ce qui n'aide pas les débutants qui se retrouve confronté aux anciennes norme (en réalité plus difficile à apprendre que les nouvelles) ou une espèce de patchwork mal imbriqué.

[Bousk]

L'avantage c'est que le langage évolue mais ne casse (quasi) pas.
Ces fonctionnalités ne t'intéressent pas ? Pas de problème, tu peux t'en passer.

Comment apprend-on à développer en C++ en 2021 ? directement C++ 20 ou on commence par le C++(98) ? Car j'ai l'impression que selon la version le code produit n'aura pas grand chose à voir.

Le C++98 est obsolète à souhait. C++11 était le premier vrai game changer. La question elle est vite répondue.
Forcément le code a rien à voir. Il aura rien à voir non plus si tu prends un code encore plus vieux qui utilise pas la stl. Ou qui s'acharne à faire des new/delete et non utiliser unique_ptr. Ou qui continuer de créer des foncteurs quand une lambda est bien plus pratique.

sur cppreference la première phrase sur les modules est : "Modules are orthogonal to namespaces". Ça ne donne pas envie d'aller plus loin.

Je vois pas en quoi cette phrase pleine de sens pourrait rebuter.
C'est une information importante voire primordiale. C'est plutôt ta réaction qui est alarmante..

Honnêtement j'ai perdu le fil depuis C++ 14.
A qui sont destinées ces nouveautés ?

C'est sûr que si tu t'intéresses tous les 7 ans, ça va pas être simple de suivre...
C'est destiné entre autre à ceux qui l'ont mis en place, et aux codebases qui suivent les évolutions.
Ça simplifie des trucs, ou ajoutent des possibilités.
Si ton job utilise encore C++98, tu en bénéficieras pas et en verras sûrement pas les bénéfices et avantages.
Tu peux continuer à ignorer les move semantic ou te passer de constexpr. Tu peux aussi ne jamais utiliser de templates si ça te chante. Pour autant ces outils existent et ont une utilité réelle.

[lefjuls]

Je suis d'accord je force le trait mais comment motiver un jeune développeur à faire du C++ ?
Sachant que lorsqu'il va arriver en entreprise pour développer sur un logiciel déjà existant il aura au mieux un code C++14 avec des vieux reliquats de C++(98).
Le C++ n'est pas "sexy" comme un "nouveau" langage (Rust ou Go par exemple) et n'a pas la simplicité apparente d'un python ou java.

Ensuite ma question sur boost peut être généralisée à d'autres librairies. J'ai l'impression qu'il faudra attendre que les librairies utilisent les modules pour pouvoir tirer un réel avantage de cette fonctionnalité. Si on m'explique le contraire tant mieux ;-)
Mais de toutes façons il y aura un problème de rétrocompatibilité. C'est une peu comme si l'on passait à un nouveau langage sans vraiment le dire.

La même question va se poser pour tous les outils comme par exemple CMake.

Est-ce que les entreprises vont faire l'effort d'adopter les nouveautés du C++ ou garderont le vieux code et feront une refonte dans un autre langage lorsqu'il n'y aura plus le choix ?