Les fonctionnalités intégrées au C++17 ont été décidées au cours de la réunion d'Oulu
Découvrez ce que sera le nouveau standard
Le 2016-06-27 21:19:53, par LittleWhite, Responsable 2D/3D/Jeux
Le comité autour du C++ s'est une nouvelle fois réuni afin de décider du contenu de la nouvelle version du langage de programmation C++.
Le comité a conclu une entente et la liste des fonctionnalités ne changera plus. Voici la liste des fonctionnalités qui intègreront C++17 :
Du côté des fonctionnalités la bibliothèque standard, les quatre points suivants ont été acceptés :
Pour rappel, il y a trois mois (lors de la réunion précédente), le comité s'était accordé pour intégrer les fonctionnalités suivantes :
Et pour la bibliothèque standard :
Comme nous l'avions vu, les concepts ne feront pas partie du C++17. Vous pouvez voir la liste complète des fonctionnalités ici.
Évidemment, une nouvelle version du langage n'est rien si les compilateurs ne la supportent pas. On pourra donc se renseigner sur le progrès du support pour clang ici et pour libc++ ici.
Votre opinion
Avez-vous suivi les évolutions du C++17 ? Qu'est-ce qui vous intéresse le plus dans les nouvelles fonctionnalités ?
Envisagez-vous de l'intégrer dans vos projets au plus tôt ? Comment gérez-vous une transition ?
Source
Page IsoCPP sur les fonctionnalités du langage
Le comité a conclu une entente et la liste des fonctionnalités ne changera plus. Voici la liste des fonctionnalités qui intègreront C++17 :
- allocation dynamique de mémoire pour les données sur alignées : en effet, depuis C++11, vous pouviez spécifier l'alignement d'une structure avec alignas(). Toutefois, lors d'une allocation dynamique, il fallait vous-même gérer la taille de la mémoire alignée tout en prenant en compte, manuellement, l'alignement ;
- déduction des arguments de template pour les classes templates ;
- mot clé auto pour les templates : permet de définir le type utilisé dans un template au moment de l'instanciation du template ;
- garantie sur l'omission de la copie : notamment pour permettre à une fonction de renvoyer un objet impossible à déplacer (et aussi, de ne pas avoir à toujours définir le constructeur de copie et de déplacement lorsqu'ils ne sont pas du tout utilisés) ;
- une version affaiblie de l'ordre d'évaluation fixe pour les expressions : pour enlever toute ambiguïté sur un code tel que f(i++,i) ;
- contexpr if : condition traitée lors de la compilation ;
- garantie forward progress : amélioration de la formulation du standard ;
- variables inline ;
- liaisons structurées ;
- if et switch (regroupement de l'initiation et de la condition) : nouvelle syntaxe pour le mot clé if, permettant d'écrire if (status_code err = fct(); err != SUCCESS).
Du côté des fonctionnalités la bibliothèque standard, les quatre points suivants ont été acceptés :
- le C++17 repose sur C11 et non pas C98 ;
- variant<> : union avec protection du type ;
- destroy(_at|_n), uninitialized_move(_n), uninitialized_value_construct(_n), uninitialized_default_construct(_n) ;
- déplacement d'éléments pour map<>,unordered_map<>, set<>, and unordered_set<> ;
- réservation de std[0-9]+ pour les standards futurs.
Pour rappel, il y a trois mois (lors de la réunion précédente), le comité s'était accordé pour intégrer les fonctionnalités suivantes :
- attributs [[fallthrough]], [[nodiscard]], [[maybe_unused]] ;
- constexpr lambdas ;
- généralisation des boucles sur ensemble ;
- capture de *this dans les lambdas ;
- valeurs littérales hexadécimales pour les nombres à virgules flottantes ;
Et pour la bibliothèque standard :
- (parts of) Library Fundamentals TS v1 ;
- Parallelism TS v1 ;
- File System TS v1 ;
- fonctions mathématiques spéciales ;
- hardware_*_interference_size ;
- .is_always_lockfree() ;
- clamp() ;
- non-const .data() pour les chaînes de caractères.
Comme nous l'avions vu, les concepts ne feront pas partie du C++17. Vous pouvez voir la liste complète des fonctionnalités ici.
Évidemment, une nouvelle version du langage n'est rien si les compilateurs ne la supportent pas. On pourra donc se renseigner sur le progrès du support pour clang ici et pour libc++ ici.
Votre opinion
Source
Page IsoCPP sur les fonctionnalités du langage
-
grunkModérateurLes types de base , les (raw) pointer sont toujours là , que ce soit C++11 ou 17.
L'évolution apporte juste des simplifications qui au contraire évite les erreur très commune du C++.
Tu peux très bien faire un soft complet en c++11 sans utiliser auto si ca te convient pas.
De la même manière tu peux très bien choisir de faire des new/delete plutôt qu'un simple shared_ptr , faut juste pas oublier de désallouerle 28/06/2016 à 8:45 -
MingolitoMembre extrêmement actifEn même temps C++ à mon avis c'est pas destiné aux débutants et aux amateurs. Pour les amateurs débutants dans ton genre le Python c'est beaucoup plus simple en effet.le 28/06/2016 à 1:59
-
jblecanardMembre expertM. Stroustrup est un des plus fervents défenseurs des nouvelles fonctionnalités du C++, essayer de prendre la compatibilité comme un argument pour la non évolution est quand même assez vide de sens. Que ça te plaise ou non, le langage évolue, les IDE aussi, les usages aussi. Donc même si tu estimes que ça devrait pas être le cas, c'est concrètement ce qui se passe, et si tu ne t'adaptes pas, ta valeur sur le marché du travail va chuter, et ce sera tant pis pour toi. Et c'est vrai dans tous les secteurs de l'informatique, C++ ou autre. Les développeurs qui vivent enfermés dans le passé et leur habitudes sont une vraie plaie pour les projets.le 01/08/2016 à 10:41
-
nikko34Membre éprouvéA noter que le code métier n'a pas à utiliser tous les systèmes plus complexes du C++.
Le but c'est de faire des librairies complexes avec beaucoup de possibilités mais qui rendent le code métier simple.
Franchement pour ceux qui utilisaient boost/le c++ moderne, il n'y a pas de gros changement avec C++11.
Pourquoi utiliser des pointeurs nus quand on sait qu'ils ne sont pas safe et que c'est si simple avec les pointeurs intélligents? (et bien sûr le fait qu'on doit utiliser les pointeurs en C++ que quand on en a vraiment besoin).le 28/06/2016 à 10:55 -
jblecanardMembre expertLes gens qui se plaignent qu'il faut mettre à jour ses connaissances au fil des ans en informatique n'ont pas tout compris à leur métierle 29/07/2016 à 10:17
-
JolyLoicRédacteur/ModérateurJ'évite de trop répondre à ce fil de discussion qui part dans tous les sens de manière que je n'arrive pas à suivre. Je vais donc me limiter aux éléments factuels.
Bjarne n'est plus le "chair of evolution". Il a cédé sa place depuis quelque temps déjà à Ville Voutilainen pour se concentrer plus sur certaines propositions qui lui tiennent à cœur. Et il n'a pas plus de pouvoir que n'importe quel membre du comité, même s'il a plus d'influence que certains. La preuve en est que la plupart de ses dernières propositions ont été rejetées (ce que je trouve très dommage pour certaines).
Je n'ai rien compris à la remarque sur le safe coding (ça ressemble à une citation, mais de qui, dans quel contexte ?). Je sais que Bjarne a travaillé avec Microsoft et d'autres sur des moyens de rendre le C++ plus sûr en permettant en particulier à du dataflow intra-procédural d'apporter suffisamment d'informations pour être utile, en enrichissant la sémantique des paramètres des fonctions. Ça s'est traduit pour l'instant au niveau du langage par des propositions sur les span, qui ne sont pas encore acceptées je crois. Et en dehors du standard, par des règles de codage ainsi que par une bibliothèque de support pour ces règles (https://github.com/isocpp/CppCoreGui...eGuidelines.md et https://github.com/Microsoft/GSL). Mais c'est loin d'être le seul sujet sur lequel Microsoft et actif (tout comme les gens de gcc ou de clang, d'ailleurs, à eux 3, ils forment la majorité des participants actifs au standard).le 17/08/2016 à 9:20 -
Luc HermitteExpert éminent séniorFranchement, vu la lenteur du processus, comparé aux autres langages et frameworks, je suis plus dans le camp des "ça va pas assez vite" que le contraire.
Et oui, il faut toujours/régulièrement se mettre jour. A croire que le fait que le C++ n'ait pas évolué pendant 13 ans fut une force.le 28/06/2016 à 14:47 -
ParseCoderMembre avertiJe ne comprend pas les commentaires précédents. Le C++ moderne a gagné en cohérence et en performance. Il y a des choses intéressantes aussi dans le C# par exemple, mais pour obtenir des perfs correctes on peut être amené à faire des bidouilles assez moches. Donc merci mais je reste en C++.le 28/06/2016 à 10:00
-
EhonnMembre chevronnéBjarne Stroustrup n'impose rien du tout, il est naturellement écouté au sujet de l'évolution de C++
mais il ne faut pas oublier que le C++ est un langage normalisé.
La compatibilité avec le C++ archaïque et le C (qui n'est pas stricte), a des avantages et des inconvénients
mais je suis convaincu que c'est l'une des raisons au succès du C++.
Généralement, les approches bibliothèques sont préférables à l'introduction de nouveaux mots clés ou nouvelles syntaxes.
Cependant, l'approche bibliothèque est limitée.
Les nouveaux mots clés et nouvelles syntaxes demandent plus de travail aux compilateurs,
il font donc de nouvelles versions.
GCC et Clang (voir liens de mon précédent message) implémentent (une partie de) la norme avant sa sortie officielle.
Visual Studio a beaucoup progressé "dans le bon sens" depuis C++11.
(Pour « C++BUILDER », je ne sais pas.)
GCC et Clang sont multiplateformes, libres, gratuits et open source.
Certaines versions de Visual Studio sont gratuites.
Il n'y a aucune vraie excuse pour ne pas mettre les compilateurs à jour (dans la grande majorité des cas).
C++17 demandera une mise à jour des compilateurs.
Entre les corrections de bugs, l'amélioration des temps de compilation, le développement de nouvelles techniques d'optimisation,
les compilateurs n'ont pas besoin d'une nouvelle norme du langage pour proposer des mises à jour.le 30/07/2016 à 16:05 -
EhonnMembre chevronnéPour le support des normes C++ par Visual Studio : https://msdn.microsoft.com/fr-fr/library/hh567368.aspx
Et voici la version à priori gratuite : https://www.visualstudio.com/fr-fr/products/visual-studio-community-vs.aspx
Je suis d'accord pour dire que Bjarne Stroustrup est très écouté dans le milieu (à juste titre) mais s'il dirigeait à lui seul les évolutions du langage,
on aurait les concepts et la surcharge de l'opérateur . en C++17.
C'est difficile de le faire passer pour le "dictateur" du C++.le 31/07/2016 à 16:58