Depuis la sortie de C++11, la langage C++ a connu de nombreuses évolutions: C++14, C++17 et enfin C++20 l'an dernier.
Cependant, ce rythme de sortie semblait assez lent aux vrais amateurs de C++, aussi le C++omité de standardisation a-t-il décidé de sortir une nouvelle version, affectueusement nommée C++2000. Fidèle à sa volonté de simplification du langage, le C++omité n'a intégré que les fonctionnalités les plus attendues et nécessaires :
- Une nouvelle syntaxe pour apporter la puissance des template à l'assembleur inline, en réutilisant le mot clef
registerqui tombait en obsolescence :
template<register r0, register r1>
__asm
{
mov r0, num ; Get first argument
mov r1, power ; Get second argument
shl r0, cl ; 2 to the power of CL
}
Malgré un fort lobby de la communauté hardware, la possibilité d'utiliser ces fonctions assembleur template dans un contexte constexpr a été repoussée à la prochaine version, C++4000.
- Un nouveau mot clef,
constfork, permet désormais d'appeler un processus externe pendant la compilation, et d'injecter sa sortie dans le processus en cours. Cette fonctionnalité s'inscrit dans la volonté déjà bien amorcée de supprimer le préprocesseur, puisqu'elle rend obsolète l'utilisation des#include
// #include <iostream>
constfork "cat /usr/include/c++/v1/iostream"
Nul doute que cette fonctionnalité permettra également de simplifier le système de build en intégrant les générateurs de code directement dans le fichier qui les utilise.
// generate header file for python compatibility
constfork "swig /mon/fichier/python.py -o -"
Les en-têtes de
<iostream>ont reçu un traitement spécial qui permet de les utiliser dans un contexteconstexpr. Cela devrait faciliter le debug d'applications en permettant d'afficher des messages de traces pendant la compilation, voire de demander des entrées utilisateur pendant la compilation, rendant ainsi le processus de compilation plus intéractif.Afin de contrer la montée du langage Rust qui menace la communauté C++, le C++omité a également pris la (très sage, à mon avis) décision d'interdire les erreurs de segmentation. Grâce à cette décision, le C++ est enfin un langage sûr, on se demande pourquoi cette décision n'a pas été prise plus tôt.
Je me réjoui que le C++omité prenne enfin des décisions fortes pour l'amélioration du langage. Et toi, cher lecteur ?
# Tu oublies des fritures !
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
La fonction main a été renommé en master.
Lorsqu'une compilation réussie, le compilateur joue ♪ C++ 2000 ♪ avec la voix de Johnny via Pulseaudio.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Tu oublies des fritures !
Posté par serge_sans_paille (site web personnel) . Évalué à 2. Dernière modification le 01 avril 2021 à 14:40.
constforkpermet déjà cela, à travers un[^] # Re: Tu oublies des fritures !
Posté par Toto . Évalué à 2.
constforkest-il compatible PowerShell ? Sinon, quels sont les shells supportés ?# Déjà vu ?
Posté par Jean Canazzi . Évalué à 10.
Cela fait bien longtemps que le commité C++, et Bjarne Stroustrup lui-même, a conçu les spécification d'une importante mise à jour du langage, qui devrait notamment révolutionner le naming et l'overloading. Source ici : https://www.stroustrup.com/whitespace98.pdf
Parmi les principale innovation, il faut retenir :
Il sera désormais possible d'écrire : "x y", avec l'opérateur "space" correspondant par défaut à une multiplication. Cette fonctionnalité a été réclamée par les mathématiciens, qui se plaignent que cette syntaxe marche sur le papier mais pas dans le code. Désormais c'est possible.
Ces même mathématiciens ne comprennent pas pourquoi "x y" marche, alors que "xy" non, alors que c'est sémantiquement pareil. Il sera désormais possible de surcharger l'opérateur "absence d'espace". Par défaut, le langage appliquera l'opérateur "space" (multiplication donc, sauf en cas de surcharge).
Évidemment, le point précédent ne peut pas marcher si un nom de variable possède une taille arbitraire. Ce qui, avouons le, a toujours été une fonctionnalité gadget et peu utilisée du langage. Pour simplifier la sémantique, on limitera donc désormais la taille des variables à un caractère. A une époque où l'Unicode est universellement répandu, il restera plus qu'assez de noms de variables possibles.
Les temps ont changé, tout le monde aujourd'hui utilise Word/Writer, on s'est habitué à colorer ses documents à sa guise. Pourquoi donc pas aussi son code ? Partant de ce constat, le langage tiendra compte des couleurs que vous donnez à vos variables. Intuitivement, le caractère "a" en rouge ne devrait pas correspondre à la même variable qu'un caractère "a" en jaune.
[^] # Re: Déjà vu ?
Posté par serge_sans_paille (site web personnel) . Évalué à 3. Dernière modification le 01 avril 2021 à 14:17.
C'est… excellent :-) Merci !
[^] # Re: Déjà vu ?
Posté par Sytoka Modon (site web personnel) . Évalué à 4. Dernière modification le 01 avril 2021 à 15:04.
Voir colorForth https://colorforth.github.io/cf.htm
# Bonne optique
Posté par _kaos_ . Évalué à 2. Dernière modification le 01 avril 2021 à 14:11.
Salut,
C'est bien qu'ils passent au mode Release early, release often. Ça fait un peu d'imprévu.
Matricule 23415
# glub glub
Posté par chimay . Évalué à -1.
ça sent le 🐠
[^] # Re: glub glub
Posté par Christophe --- . Évalué à 2.
Ah bon?
Homme de peu de foi !
Pour une fois que le comité propose des innovations disruptives…
# Et C++2000 ajoute également ...
Posté par SChauveau . Évalué à 10.
Et C++2000 ajoute également le support du caractère '·' (Codepoint 183, "MIDDLE DOT") dans les identifiants. On pourra donc améliorer la lisibilité du code avec des programmes inclusifs:
for (int compteur·se· = 0 ; compteur·se· < n ; ++compteur·se· ) {
if ( fsf_direct·eur·rice[compteur·se·] == richard_stallman )
throw sale_macho ;
}
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.