Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous

Identifiant
Mot de passe

Mot de passe oublié ?

Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le 26 février 2020 à 13:30, par Stéphane le calme

119 commentaires

534PARTAGES

Vous avez lu gratuitement 102 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

Votre nom : Votre e-mail :

Décrivez l'erreur que vous souhaitez porter à notre connaissance :

119 commentaires

Commenter Signaler un problème

boumchalet

Nouveau membre du Club

Le 11/09/2020 à 10:21

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.

onilink_

Membre émérite

Le 07/09/2020 à 18:52

Envoyé par zoonel

Moi je suis vite passé au C# Après mes études. Justement parce que je trouve que c'est un bon langage, élégant etc... Bref en fait les mêmes arguments que toi mais pour C# au lieu de C++. Et durant mes études j'ai appris à programmer avec c++ , et j'ai du faire du c, du java et accessoirement on a également vu toute une floppée de languages "exotiques" (haskell, etc...).
Alors ça fait longtemps que j'ai plus fais de c++ et je m’intéresse pas trop aux nouveautés même si je suis l'actualité, mais quand je vois les examples de code rien que la synthaxe me fait peur et je la trouve pas élégante pour un sou.
Néanmoins ça m’intéresse d'avoir un avis de quelqu'un qui aime le c++ et donc en quoi le trouve-tu élégant, bon, etc... ?

J'essaie de me tenir vaguement au courant sur ce qui peut se faire comme langage mais le nouveau c++ ne m'a jamais attiré, seul Rust récemment a attiré mon attention et j'ai commencé à lire le bouquin, du coup je pense complètement laisser tomber le c++ (ou du moins l'espoir que j'avais de m'y (re)mettre). (Ça me fait penser à une vidéo que j'ai vue récemment sur un top top10 des "jeux de société qu'on aurait voulu aimé", je pense qui si c'était une vidéo sur les langages de programmation alors c++ arriverait en tête pour moi. J'aurais vraiment voulu l'aimer mais non j'y arrive pas)

Pour être honnête, je pense que si je devais reprendre le dev de zéro en 2020, j'apprendrais probablement plus Rust que C++.
J'aime énormément la philosophie de C++ et le langage en lui même mais il y a quand même un point noir sur le tableau: il reste trop de choses de C et C++98 (parce qu'il faut garder une retro compatibilité, Rust n'a pas ce soucis, étant jeune) qui rendent C++ bien moins moderne que ce qu'il pourrait être.

Pour ce que j'aime du C++ moderne:
- le langage n'est pas explicitement désigné en prenant les utilisateurs pour des cons. Des choses comme les pointeurs ne sont pas cachés sous un autre nom avec moins de features juste parce que dans l'imaginaire collectif "pointeur == compliqué" (ce qui est faux bien entendu).
- sur le même principe il n'y a pas de GC, mais des pointeurs intelligents, qui IMO sont beaucoup plus pratiques (et applicables dans d'autres domaines que juste gérer la mémoire), mais surtout cela permet d'avoir une durée de vie définie sur nos objets, et la construction/destruction est bien plus simple au final.
- une grosse partie de la philosophie de C++ c'est "ce qu'on peut faire à la compilation, on le fait a la compilation", et ça permet d'avoir des objets pratiques comme unique_ptr qui vont avoir absolument zéro overhead, mais en plus ça permet aussi de voir pas mal d'erreurs a la compilation, et ne pas attendre que ça pète au runtime. Et sur ce point Rust a l'air vraiment génial avec son borrow checker.
- je trouve tout le principe des templates et ce que l'on peut en faire complètement génial. Je sais pas si tu as déjà vu les patterns genre CRTP ou encore le polymorphisme statique, je trouve juste ça très élégant en plus d'être pratique (et très performant). Les templates c'est vraiment très puissant (il y a qu'a voir la lib standard, et boost), et on à rarement vu autant de possibilités dans d'autres langages, même si j'ai cru comprendre qu'en Rust il y avait de quoi faire des choses équivalentes, peut être plus facilement.
- chaque nouveau standard nous amène des outils incroyables, toujours plus puissants, et qui réparent petit à petit tous les problèmes majeurs du langage

Après y a aussi tous les trucs obvious qui font que personnellement, je préfère un langage natif à un langage qui tourne dans une VM.
On comprend mieux ce qu'on manipule, ça consomme moins, ça permet d'utiliser des outils plus "standards"... et en C++ on profite quand même de tout l'écosystème qu'il y a déjà autour de C (outils, bibliothèques), d'autant que moi je suis sous Linux et l'OS est vraiment très adapté à ce niveau.

Néanmoins, C++ n'est vraiment pas un langage safe (même si on suit beaucoup de règles, comme les C++ core guideline etc qui permettent de grandement limiter la casse), et je considère perso que ce n'est pas du tout un bon choix dans tout domaine qui nécessite du code vraiment safe (genre serveurs). Moi je développe un jeu donc ça ne me pose pas trop de problèmes, mais dans certains domaines il faut vraiment oublier le C++.

Bon, j'oublie probablement plein de choses, mais ça te permettra de voir mon ressentis général sur la chose je pense

Par contre j'ajouterais que savoir programmer en C++, ça ne se fait pas en quelques années d'études. J'ai fait genre 4 ans de C++ a la fac, et mon niveau était vraiment lamentable (et celui de mes profs encore pire) malgré le fait que je pratiquais pas mal (j'avais l'impression d'être bon, mais la suite m'a montré que non).
Par contre quand je suis allé bosser, et que j'ai rencontré des personnes très compétentes, dont une personne qui maîtrise vraiment le langage, ça a changé beaucoup de choses et mon niveau a été propulsé d'un coup, bien plus en très peu de temps qu'en toutes mes années d'étude cumulées.
Et je pense que c'est le même problème pour la plupart des langages quand on étudie, mais a mon avis C++ est l'un des pires à ce niveau, car tout le monde pense savoir le connaître ou le maîtriser... sans savoir en faire, en fait.
C++ est un langage difficile a apprendre en profondeur, mais pas du tout pour les raisons que la plupart des étudiants pensent (pointeurs, gestion de la mémoire, bas niveau).

Le 18/12/2020 à 11:54

Envoyé par 23JFK

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

Pourquoi ? Tu développes ton propre compilateur ?

Pyramidev

Expert éminent

Le 05/01/2021 à 16:17

Envoyé par lefjuls

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!

stardeath

Expert confirmé

Le 28/02/2020 à 16:10

en tout cas, visiblement le problème de syntaxe de c++ ne pose pas de problème qu'à moi, vu la proposition epochs : http://www.open-std.org/jtc1/sc22/wg...0/p1881r1.html

23JFK

Inactif

Le 17/12/2020 à 21:18

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

Pyramidev

Expert éminent

Le 11/09/2020 à 11:38

Bonjour,

Envoyé par boumchalet

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

jo_link_noir

Membre expert

Le 18/12/2020 à 17:10

Envoyé par onilink_

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/wg...1/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.

Bktero

Modérateur

Le 29/12/2020 à 14:53

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)

Pyramidev

Expert éminent

Le 30/12/2020 à 15:47

Envoyé par lefjuls

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 :

Envoyé par lefjuls

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

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

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.

Envoyé par lefjuls

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.

Commenter Signaler un problème

Identifiez-vous

Créer un compte

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

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