Discussion :

[LittleWhite]

Les fonctionnalités intégrées au C++17 ont été décidées au cours du meeting à Oulu

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 :

• 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

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

[bazzyx]

Bonsoir c koi ca! j'avais decidé d'apprendre ce langage plutot que python.ca devient une horreur inutilisable.le developpement comme l'entretient deviennent quasi impossible seul.c'est 1 risque d'érreurs

majeur.les compilateurs et edi seront difficiles a mettre au point.cela va mettre en cause la portabilité des programmes. leurs financement aussi. on risque 1 fork à partir de c11. ils ont pondu 1 truc

indigeste, incomprehensible par la majorité des developpeurs. je mise sur python java modernisé et c sharp. merci ! je cours vite me laver les yeux de c17.

[Mingolito]

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

[therev123]

Moi qui voulais me remettre à programmer en C++, ayant appris avec les bon vieux standard comme les type float int double et les bonne vieille méthode de POO et de pointeur. J'ai voulu passer au C++ 11 et bien franchement je trouve que c'est de la vrai merde, tout est ambigue, les putins de mots clé comme auto, shared_ptr tout plein de mots clé barbare, pas moyen d'apprendre, de comprendre et d'exploiter c'est nouveau concepts à partir des bonnes vieilles bases du langage. Moi je suis tout perdu, je re-mets énormement en question mes connaissances sur le c++, bien franchement j'ai pas suivi son développement et je me suis encore moins préparé à l'arriver de ces nouvelles normes, si je m'avais pencher sur la bibliothèque boost j'en serais peut-etre pas rendu là, j'aurais été mieux préparé, mais bon il n'est jamais trop tard.

[grunk]

Les 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ésallouer

[Luc Hermitte]

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ésallouer

Au détail que c'est impossible (la faute aux exceptions) de garantir un libération de la mémoire sans encapsuler les ressources dans des capsules RAII. Et ça, depuis 98 (*), le seul truc qui change c'est que l'on n'a plus besoin d'une bibliothèque externe pour disposer d'un tel service.

De la lecture nécessaire pour une mise à jour rapide du truc le plus important par rapport à la pratique du C with classes: http://alexandre-laurent.developpez....ou-exceptions/

(*) enfin, on avait bien auto_ptr, et ses soucis comme vector<auto_ptr<>> qui ne marchait pas.

[mintho carmo]

des bonnes vieilles bases du langage

Justement, elles sont vieilles. Pourquoi continuer à utiliser des syntaxes complexes et potentiellement dangereuses (cf le message de Luc), s'il est possible de faire la même chose plus simplement et safe.

Les contraintes en termes de conception de logiciels ont évoluées, et les méthodologies de développement ont suivi. Soit il fallait changer de langage pour suivre ces nouveaux besoins, soit il fallait faire évoluer le C++. L'intérêt du C++ n'est pas de proposer une syntaxe vieille de 20 ans, mais de proposer les mêmes avantages qu'il y a 20 ans avec une syntaxe moderne. (Plus ou moins correctement, selon les compétences plus ou moins à jour des devs).

Et on est en 2016. Plus de 5 ans que le C++11 est normalisé. Cela fait un peu long pour se mettre à jour. Vous mettez plus de 5 ans pour apprendre un langage ?

[ParseCoder]

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

[VivienD]

Si certaines évolutions sont louables comme la déduction des arguments templates pour les classes templates et constexpr if, d'autres me laissent dubitatifs. Par exemple, la levée de l'ambiguïté de f(i++, i); n'est, à mon sens, pas nécessaire: il suffisait d'écrire f(i, i); i++; ou f(i, i + 1); i++;, ce qui est nettement plus clair.

Les 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ésallouer

Enfin quelqu'un qui comprend à la rejet du mot-clef auto et ma préférence pour l'utilisation des pointeurs nus par rapport à celles des pointeurs intelligents.

[nikko34]

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

[foetus]

Et on est en 2016. Plus de 5 ans que le C++11 est normalisé. Cela fait un peu long pour se mettre à jour. Vous mettez plus de 5 ans pour apprendre un langage ?

Tu parles de langage. Hors, le C++1y est une surcouche/ amélioration/ [armure] du C++. Donc apprendre un langage, comme tu y vas

De plus, vu comment le C++14 et le C++17 améliore/ déprécie/ change le C++11, je me dis que ceux qui ont appris le C++11 n'ont pas loupé le train, mais changent tous les 2 ans leurs acquis

À près on va, à coup sûr, me dire: les changements sont minimes, les changements ont été anticipés avec des bidouilles, les changements ne touchent qu'à la partie "faire une bibliothèque", les changements sont du sucre syntaxique ...

[nikko34]

Ben vu que tu peux continuer à programmer de la même manière qu'avant, les changements restent minimes oui.

[foetus]

Tellement minimes que le C++11 remplace le C++98 comme norme par défaut.

[nikko34]

Et donc? tes progs compilent plus?

[Luc Hermitte]

De plus, vu comment le C++14 et le C++17 améliore/ déprécie/ change le C++11, je me dis que ceux qui ont appris le C++11 n'ont pas loupé le train, mais changent tous les 2 ans leurs acquis

À près on va, à coup sûr, me dire: les changements sont minimes, les changements ont été anticipés avec des bidouilles, les changements ne touchent qu'à la partie "faire une bibliothèque", les changements sont du sucre syntaxique ...

Franchement, 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.

[GEP1096]

On vit une véritable accélération ...
Les compilateurs vont-ils suivre ?

[GEP007]

Bjarne annonce qu'il y aura une volonté de simplification aussi bien à l'écriture qu'à l'enseignement du C++ tant mieux si c'est le cas.

L'avantage du C++ réside dans l'assurance que les codes doivent rester compatibles avec les premiers programmes en C++ des années 80 voir du C.

Donc, il n'y a pas de risques de peaufiner son C++11 déjà riche avant de se lancer sur du C++17 sûrement pas supporté par les compilateurs récents...

Et faudra-t-il déjà racheter une nouvelle version de compilateur ?

[Ehonn]

Bjarne annonce qu'il y aura une volonté de simplification aussi bien à l'écriture qu'à l'enseignement du C++ tant mieux si c'est le cas.

C'est déjà le cas avec C++11 et C++14.

L'avantage du C++ réside dans l'assurance que les codes doivent rester compatibles avec les premiers programmes en C++ des années 80 voir du C.

Avec le C++ et le C, normalisés, la compatibilité est globalement là et, malgré quelques différences, il est facile d'écrire du code compatible.

Donc, il n'y a pas de risques de peaufiner son C++11 déjà riche avant de se lancer sur du C++17 sûrement pas supporté par les compilateurs récents...

?
GCC et Clang supportent déjà une (bonne) partie de C++17 :
- https://gcc.gnu.org/projects/cxx-status.html#cxx1z
- http://clang.llvm.org/cxx_status.html#cxx17

Et faudra-t-il déjà racheter une nouvelle version de compilateur ?

GCC et Clang sont multiplateformes, libres, gratuits et open source.

[jblecanard]

Les gens qui se plaignent qu'il faut mettre à jour ses connaissances au fil des ans en informatique n'ont pas tout compris à leur métier

[GEP007]

Les gens qui se plaignent qu'il faut mettre à jour ses connaissances au fil des ans en informatique n'ont pas tout compris à leur métier

DITES CELA A BJARNE STROUSTRUP QUI OBLIGE UNE COMPTABILITÉ ASCENDANTE TOTALE

Pouvoir associer un programme écrit en archaïque C++14482-1985 sans aucune variable booléenne avec des composants C++C++14482-2011...
C'est cela l'informatique selon Bjarne STROUSTRUP, le reste est du commerce !

La pérennisation des programmes sans avoir à le récrire doit être le but ultime du programmeur Bjarne STROUSTRUP
Il ne faut pas confondre évolution ( garantie d'avenir ) et reconstruction dans une nouvelle variante ( preuve d'erreur ou de volonté commerciale )...

Les vraies questions sont :

Pourquoi devoir acheter un nouveau C++BUILDER ou un nouveau Visual Studio pour pouvoir intégrer C++11 puis maintenant devoir acheter un nouveau C++BUILDER ou un nouveau Visual Studio pour pouvoir intégrer C++17 ?

Les constructeurs vont-ils traîner la savate comme avec C++14482-2003 qui a mis des années pour être intégré dans les compilateurs ?

Et quel sera l'enjeux du C++17 MAJ ou Extension ?